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1 Scope 



The present document specifies the signalling protocol for the support of the Short Message Service (SMS) at the 

Q reference point between Private Integrated services Network eXchanges (PINXs) connected together within a Private 

Integrated Services Network (PISN). 

NOTE: The Short Message Service is a special type of basic service but is described in the present document as a 
supplementary service. 

The Short Message Service is a service which permits a served user to send a message of limited size to another user in 
the same PISN or another network. 

The Q reference point is defined in ECMA-133. 

Service specifications are produced in three stages and according to the method specified in ETS 300 387. The present 
document contains the stage 3 specification for the Q reference point and satisfies the requirements identified by the 
stage 1 and stage 2 specifications in ECMA-324. 

The signalling protocol for SMS operates on top of the signalling protocol for the connection oriented call independent 
APDU transport mechanism and uses certain further aspects of the generic procedures for the control of supplementary 
services specified in ECMA-165. 

The present document also specifies additional signalling protocol requirements for the support of interactions at the 
Q reference point between SMS and supplementary services and ANFs. 

The present document is applicable to PINXs which can be interconnected to form a PISN. 



2 Conformance 

In order to conform to the present document, a PINX shall satisfy the requirements identified in the Protocol 
Implementation Conformance Statement (PICS) proforma in annex A. 



References (normative) 



The following standards contain provisions which, through references in this text, constitute provisions of this Standard. 
All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the 
possibility of applying the most recent editions of the standards indicated below. 

In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the 
appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. 

ETSI ETS 300 387: "Private Telecommunication Network (PTN); Method for the specification of basic and 
supplementary services (1994)". 

ETSI TS 100 901: "Digital cellular telecommunications systems (Phase 2+); Technical realization of the Short Message 
Service (SMS) (GSM 03.40)". 

ECMA-133: "F*rivate Integrated Services Network (PISN) - Reference Configuration for PISN Exchanges (PINX) 
(International Standard ISO/IEC 11579-1)". 

ECMA- 143: "F*rivate Integrated Services Network (PISN) - Circuit Mode Bearer Services - Inter-Exchange Signalling 
Procedures and Protocol (International Standard ISO/IEC 11572)". 

ECMA- 164: "F*rivate Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Name Identification 
Supplementary Services (International Standard ISO/IEC 13868)". 

ECMA-165: "F*rivate Integrated Services Network (PISN) - Generic Functional Protocol for the Support of 
Supplementary Services - Inter-Exchange Signalling Procedures and Protocol (International Standard ISO/IEC 11582)". 
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ECMA-242: "Private Integrated Services Network (PISN) - Inter -Exchange Signalling FYotocol - Message Waiting 
Indication Supplementary Service (International Standard ISO/IEC 15506)". 

ECMA-324: "Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - 
Short Message Service". 

ISO/IEC 10646-1: "Information technology - Universal Multiple-Octet Coded Character Set (UCS) - 
Part 1: Architecture and Basic Multilingual Plane". 

ISO 8601: "Data elements and interchange formats - Information interchange - Representation of dates and times". 

GSM 03.38: "Digital cellular telecommunications systems (Phase 2+) (GSM); Alphabets and language-specific 
information". 

GSM 03.42: "Digital cellular telecommunications systems (Phase 2+); Compression algorithm for text messaging 
services". 

GSM 04.11: "Digital cellular telecommunications system (Phase 2+) (GSM); Point-to-Point (PP) Short Message 
Service (SMS) support on mobile radio interface". 

GSM 09.02: "Digital cellular telecommunications systems (Phase 2+) (GSM); Mobile Application Part (MAP) 
specification". 

ITU-T Recommendation 1.112 (1993): "Vocabulary of terms for ISDNs". 

ITU-T Recommendation 1.210 (1993): "Principles of telecommunication services supported by an ISDN and the means 
to describe them". 

ITU-T Recommendation Z.IOO (1999): "Specification and description language (SDL)". 



4 Definitions 

For the purposes of the present document the following terms and definitions apply. 

4.1 External definitions 

The present document uses the following terms defined in other documents: 

Application Protocol Data Unit (APDU): (ECMA-165) 

Call, Basic Call: (ECMA-165) 

Call Independent Signalling Connection: (ECMA-165) 

Command: (ECMA-324) 

End PINX: (ECMA-165) 

Message Centre: (ECMA-324) 

Message Centre Case: (ECMA-324) 

Private Integrated services Network eXchange (PINX): (ECMA-133) 

Private Integrated Services Network (PISN): (ECMA-133) 

Receiving User: (ECMA-324) 

Sending User: (ECMA-324) 

Service Centre: (ECMA-324) 

Short Message: (ECMA-324) 



ETSI 



11 



ETSI TS 101 991 VI. 1.1 (2001-08) 



Short Message Waiting Data: (ECMA-324) 

Status Report: (ECMA-324) 

Signalling: (ITU-T Recommendation 1.112) 

Supplementary Service: (ITU-T Recommendation 1.210) 

Terminal Case: (ECMA-324) 



4.2 



Other definitions 



4.2.1 Receiving User Case 

The configuration when the Terminal Case is provided for the Receiving User, i.e. no Receiving User Message Centre 
is involved in the SMS procedures. 

4.2.2 Receiving User PINX 

The Receiving User PINX is the PINX serving the Receiving User. 

4.2.3 Sending User PINX 

The Sending User PINX is the PINX serving the Sending User. 

4.2.4 Sending User IVIessage Centre 

The Message Centre serving the Sending User. 

4.2.5 Siiort IVIessage Entity 

A generic term for an entity that is capable of handling one or more SMS specific procedures. This can be either the 
Sending Users terminal, the Sending User PINX, the Sending User Message Centre, the Service Centre, the Receiving 
User Message Centre, the Receiving User PINX or the Receiving Users terminal. 

4.2.6 Receiving User Message Centre 

The Message Centre serving the Receiving User. 



Acronyms 



For the purposes of the present document, the following abbreviations apply: 



ANF 

APDU 

ASN.l 

GSM 

ISDN 

MC 

NFE 

PDU 

PICS 

PINX 

PISN 

PSSl 

QSIG 

SC 



Additional Network Feature 

Application Protocol Data Unit 

Abstract Syntax Notation One 

Global System for Mobile communication 

Integrated Services Digital Network 

Maintenance Centre 

Network Facility Extension 

Protocol Data Unit 

Protocol Implementation Conformance Statement 

Private Integrated services Network eXchange 

Private Integrated Services Network 

Private Signalling System number one 

Q Interface SignallinG protocol (ECMA standard) 

Service Centre (used for SMS) 
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SCA 


Service Centre Address 


SDL 


Specification and Description Language 


SIM 


Subscriber Identity Module 


SM 


Short Message 


SMS 


Short Message Service 


SMSC 


Short Message Service Centre 


SMWD 


Short Message Waiting Data 


SR 


Status Report 


ss 


Supplementary Service 


UDH 


User Data Header 



Signalling Protocol for the support of SMS 



6.1 SMS description 

Short Message Service is a service which is offered to a user in a PISN and which enables the user to send and receive 
Short Messages to and from another user in a PISN or in another (e.g. GSM) network. 

The PISN transfers the Short Message from the Sending User to an SC and from the SC to the Receiving User. 

6.2 SMS operational requirements 

6.2.1 Provision/Withdrawal 

Provision and withdrawal shall be in accordance with clause 6.2. 1 of ECMA-324. 

6.2.2 Requirements on a Sending User PINX 

Generic procedures for the call independent control (connection oriented) of supplementary services, as specified in 
ECMA-165 for an Originating-PINX and for a Terminating-PINX, shall apply. 

6.2.3 Requirements on a Sending User IVIessage Centre 

Generic procedures for the call independent control (connection oriented) of supplementary services, as specified in 
ECMA-165 for an Originating-PINX and for a Terminating-PINX, shall apply. 

6.2.4 Requirements on a Service Centre 

Generic procedures for the call independent control (connection oriented) of supplementary services, as specified in 
ECMA-165 for an Originating-PINX and for a Terminating-PINX, shall apply. 

6.2.5 Requirements on a Receiving User PINX 

Generic procedures for the call independent control (connection oriented) of supplementary services, as specified in 
ECMA-165 for an Originating-PINX and for a Terminating-PINX , shall apply. 

6.2.6 Requirements on a Receiving User IVIessage Centre 

Generic procedures for the call independent control (connection oriented) of supplementary services, as specified in 
ECMA-165 for an Originating-PINX and for a Terminating-PINX, shall apply. 
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6.3 SMS coding requirements 
6.3.1 Operations 

The following operations defined in Abstract Syntax Notation One (ASN.l) in table 1 shall apply. 

Table 1 : Operations in Support of SIVIS 



Short-Message-Service-Operations-asnl-97 

{iso(l) identified-organization(3) icd-ecma(0012) standard(O) qsig-short-message-service(325) short-message- 

service-operations-asn 1 -91 { 1 ) ) 

DEFINITIONS::= 

BEGIN 

IMPORTS 

OPERATION, 

ERROR 
FROM Remote-Operations-Information-Objects 
{joint-iso-itu-t (2) remote-operations(4) informationObjects(5) versionl(O)} 

EXTENSION, Extension! } 
FROM Manufacturer-specific-service-extension-class-asn 1 -97 
{iso(l) standard(O) pss 1 -gen eric-procedures( 11582) msi-class-asnl-97(ll)} 

Name 
FROM Name-Operations-asnl-97 
{iso(l) standard(O) pssl-name(13868) name-operations-asn 1-97(1)} 

supplementaryServicelnteractionNotAUowed 
FROM General-Error-List 
{ccitt recommendation q 950 general-error-list(l)} 

PartyNumber 
FROM Addressing-Data-Elements-asn 1-97 
{iso(l) standard(O) pss 1 -gen eric-procedures( 11582) addressing-data-elements-asn 1-97(20)); 

-TYPE DEFINITIONS FOR SMS OPERATIONS FOLLOW 

Sms-Operations OPERATION ::={ 

smsSubmit I smsDeliver I smsStatusReport I smsCommand I scAlert) 

smsSubmit OPERATION ::= { 

— sent from the Sending User PINX/Sending User Message Centre to the Service Centre 

ARGUMENT SmsSubmitArg 
RESULT SmsSubmitRes 
ERRORS { smsSubmitError I 

unspecified) 
CODE local: 107) 

smsDeliver OPERATION ::= { 

— sent from the Service Centre to the Receiving User PINX or to the Receiving User Message Centre 

ARGUMENT SmsDeliverArg 
RESULT SmsDeliverRes 
ERRORS { smsDeliverError I 

unspecified) 
CODE local: 108) 
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Table 1 : Operations in Support of SIVIS (continued) 



smsStatusReport OPERATION ::= { 

— sent from the Service Centre to the Sending User PINX or to the Sending User Message Centre 

ARGUMENT SmsStatusReportArg 
RESULT SmsStatusReportRes 
ERRORS { smsStatusReportError I 

unspecified) 
CODE local: 109) 

smsCommand OPERATION ::= { 

— sent from the Sending User PINX or the Sending User Message Centre to the Service Centte 

ARGUMENT SmsCommandArg 
RESULT SmsCommandRes 
ERRORS { smsCommandError I 

unspecified) 
CODE local: 110) 

scAlert OPERATION ::= { 

— sent from the Receiving User PINX or the Receiving User Message Centre to the Service Centre 

ARGUMENT ScAlertArg 
RESULT DummyRes 
ERRORS {unspecified} 
CODE local:lll) 

-TYPE DEFINITIONS FOR SMS DATA TYPES FOLLOW 

SmsSubmitArg ::= SEQUENCE { 

destinationAddress PartyNumber, 

originatingAddress PartyNumber, 

messageReference MessageReference, 

smSubmitParameter SmSubmitParameter, 

userData UserData, 

smsExtension SmsExtension OPTIONAL) 

SmsSubmitRes ::= SEQUENCE { 

serviceCentreTimeStamp ServiceCentreTimeStamp, 
protocolldentifier [2] IMPLICIT Protocolldentifier OPTIONAL, 

userData [3] IMPLICIT UserData OPTIONAL, 

smsExtension SmsExtension OPTIONAL) 

SmsDeliverArg ::= SEQUENCE { 

originatingAddress PartyNumber, 

destinationAddress PartyNumber, 

originatingName Name OPTIONAL, 

smDeliverParameter SmDeliverParameter, 

userData UserData, 

smsExtension SmsExtension OPTIONAL) 

SmsDeliverRes ::= SEQUENCE { 

smsDeliverResponseChoiceSmsDeliverResChoice, 
smsExtension SmsExtension OPTIONAL) 
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Table 1 : Operations in Support of SIVIS (continued) 



SmsStatusReportArg ;:= SEQUENCE { 

messageReference MessageReference, 

serviceCentreTimeStamp ServiceCentreTimeStamp, 

dischargeTime DischargeTime, 

recipientAddress PartyNumber, 

recipientName Name OPTIONAL, 

destinationAddress PartyNumber, 

status Status, 

priority BOOLEAN DEFAULT FALSE, 

moreMessagesToSend BOOLEAN DEFAULT FALSE, 

statusReportQualifier BOOLEAN DEFAULT FALSE, 

protocolldentifier Protocolldentifier OPTIONAL, 

userData UserData OPTIONAL, 

smsExtension SmsExtension OPTIONAL) 

SmsStatusReportRes ::= SEQUENCE { 

smsStatusReportResponseChoice SmsStatusReportResponseChoice, 
smsExtension SmsExtension OPTIONAL) 

SmsCommandArg ::= SEQUENCE { 

destinationAddress PartyNumber, 

messageReference MessageReference, 

messageNumber MessageReference, 

protocolldentifier Protocolldentifier, 

commandType CommandType, 

commandData CommandData OPTIONAL, 

statusReportRequest BOOLEAN OPTIONAL, 

smsExtension SmsExtension OPTIONAL} 

SmsCommandRes ::= SEQUENCE { 

serviceCentreTimeStamp ServiceCentreTimeStamp, 

protocolldentifier Protocolldentifier OPTIONAL, 

userData UserData OPTIONAL, 

smsExtension SmsExtension OPTIONAL) 

ScAlertArg ::= SEQUENCE { 

originatingAddress PartyNumber, 

smsExtension SmsExtension OPTIONAL) 

DummyRes:;= CHOICE) 
null NULL, 

smsExtension SmsExtension ) 

SmSubmitParameter ::= SEQUENCE { 

protocolldentifier Protocolldentifier, 

validityPeriod ValidityPeriod OPTIONAL, 

StatusReportRequest BOOLEAN DEFAULT FALSE, 
replyPath BOOLEAN DEFAULT FALSE, 
rejectDuplicates BOOLEAN DEFAULT FALSE ) 
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Table 1 : Operations in Support of SIVIS (continued) 



SmDeliverParameter ::= SEQUENCE { 

protocolldentifier Protocolldentifier, 
serviceCentreTimeStamp ServiceCentreTimeStamp, 
priority BOOLEAN DEFAULT FALSE, 

moreMessagesToSend BOOLEAN DEFAULT FALSE, 
statusReportlndication BOOLEAN DEFAULT FALSE, 
replyPath BOOLEAN DEFAULT FALSE } 

SmsDeliverResChoice::= CHOICE { 
null NULL, 

protocolldentifier Protocolldentifier, 
userData UserData, 

resChoiceSeq ResChoiceSeq } 

ResChoiceSeq ::= SEQUENCE { 

protocolldentifier Protocolldentifier, 
userData UserData ) 

SmsStatusReportResponseChoice ::= CHOICE { 
null NULL, 

protocolldentifier Protocolldentifier, 
userData UserData, 

resChoiceSeq ResChoiceSeq ) 

MessageReference ::= INTEGER(0..255) 

SmsExtension ::= CHOICE { 

single [1]IMPLICIT Extension! { SmsExtSet} }, 

multiple [2]IMPLICIT SEQUENCE OF 

Extension { { SmsExtSet ) ) 
} 

SmsExtSet EXTENSION ::= {...} 

Protocolldentifier ::= INTEGER (0..127) 

— definition of the Protocolldentifier values and default value can be found in clause E. 1.2.1 

ServiceCentreTimeStamp ::= GeneralizedTime(SIZE(12..19)) 

— this date and time representation follows ISO 8601 

DischargeTime ::= GeneralizedTime(SIZE(12..19)) 

— this date and time representation follows ISO 8601 

ValidityPeriod ::= CHOICE{ 

validityPeriodRel [0] IMPLICIT ValidityPeriodRel, 
validityPeriodAbs [ 1 ] IMPLICIT ValidityPeriodAbs, 
validityPeriodEnh [2] IMPLICIT ValidityPeriodEnh} 

ValidityPeriodAbs ::= GenerahzedTime(SIZE(12..19)) 

— this date and time representation follows ISO 8601 

ValidityPeriodRel ::= INTEGER(0..255) 

— the rules for the encoding of ValidityPeriodRel are shown in clause E. 1.2.2 
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Table 1 : Operations in Support of SIVIS (continued) 



ValidityPeriodEnh :;= SEQUENCE! 

singleShotSM BOOLEAN DEFAULT FALSE, 

enhancedVP EnhancedVP OPTIONAL} 

EnhancedVP::= CHOICEj 

validityPeriodRel [0] IMPLICIT ValidityPeriodRel, 
validityPeriodSec [1] IMPLICIT INTEGER(0..255), 

validityPeriodSemi [2] IMPLICIT ValidityPeriodSemi} 

ValidityPeriodSemi ::= OCTET STRING (SIZE(3)) 

— Validity Period is relative in semi-octet representation, see ETSI TS 100 901, clause 9.1.2.3 

— and clause 9.2.3.12.3 

UserData::= SEQUENCE! 

userDataHeader [0] IMPLICIT UserDataHeader OPTIONAL, 

class [1] IMPLICIT INTEGER (0..3) OPTIONAL, 

compressed [2] IMPLICIT BOOLEAN DEFAULT FALSE, 

shortMessageText ShortMessageText } 

ShortMessageText::= SEQUENCE! 

shortMessageTextType ShortMessageTextType, 
shortMessageTextData ShortMessageTextData } 

ShortMessageTextType ::= INTEGER! 

iASCoded (0), — ShortMessageTextData shall contain data according to 
octetCoded (1), — the type given in ShortMessageTextType, for further 
uniCoded (2), — details see annex E. 1.3.4. 
compressedCoded (3)) (0..8) 

ShortMessageTextData ::= OCTET STRING (SIZE(0..140)) 

Status ::= INTEGER (0..255) 

— definition of status values can be found in clause E.7.6 

CommandType ::= INTEGER! 

enquiry (0), 

cancelSRR (1), 

deletePreviouslySubmittedSM (2), 

enableSRRrelatingToPreviouslySubmittedSM (3)} (0..255) 

CommandData ::= OCTET STRING (SIZE(0..157)) 

FailureCause ;:= INTEGER (0..255) 

— definition for failureCause values can be found in clause E.3.1 

UserDataHeader ::= SEQUENCE OF UserDataHeaderChoice 

UserDataHeaderChoice ::= CHOICE! 

smscControlParameterHeader [0] IMPLICIT SmscControlParameterHeader, 

concatenatedSBitSMHeader [ 1 ] IMPLICIT ConcatenatedSBitSMHeader, 
concatenated 1 6BitSMHeader [2] IMPLICIT Concatenated 1 6BitSMHeader, 

apphcationPortSBitHeader [3] IMPLICIT ApplicationPortSBitHeader, 

apphcationPortl6BitHeader [4] IMPLICIT ApplicationPortl6BitHeader, 
dataHeaderSourcelndicator [5] IMPLICIT DataHeaderSourcelndicator, 
wirelessControlHeader [6] IMPLICIT WirelessControlHeader, 

genericUserValue [99] IMPLICIT Gen ericUser Value} 
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Table 1 : Operations in Support of SIVIS (continued) 



SmscControlParameter Header ::= BIT STRING { 
sRforTransactionCompleted (0), 
sRforPermanentError (1), 

sRforTempErrorSCnotTrying (2), 
sRforTempErrorSCstillTrying (3), 
cancelSRRforConcatenatedSM (6), 
includeOrigUDHintoSR (7)} (SIZE(8)) 

ConcatenatedSBitSMHeader ::= SEQUENCE { 

concatenatedSBitSMReferenceNumber INTEGER(0. .255), 

maximumNumberOfSBitSMInConcatenatedSM INTEGER(0..255), 
sequenceNumberOfSBitSM INTEGER(0..255) } 

Concatenated 16BitSMHeader ::= SEQUENCE! 

concatenated 1 6BitSMReferenceNumber INTEGER(0. .65536), 
maximumNumberOf 1 6BitSMInConcatenatedSMINTEGER(0. .255), 
sequenceNumberOfl6BitSM INTEGER(0..255) } 

ApplicationPortSBitHeader ::= SEQUENCE! 
destinationSBitPort INTEGER(0..255), 

originatorSBitPort INTEGER(0. .255) } 

ApplicationPortl6BitHeader ::= SEQUENCE! 

destination 16BitPort INTEGER(0..65536), 

originator 16BitPort INTEGER(0..65536) } 

DataHeaderSourcelndicator ::= INTEGERj 

originalSender (1), — valid in case of Status Report 

originalReceiver (2), — valid in case of Status Report 

sMSC (3))(0..255) — can occur in any message or report 

WirelessControlHeader ::= OCTET STRING 

GenericUserValue ::= SEQUENCE! 
parameter Value INTEGER(0..255), 
genericUserData OCTET STRING} 

smsDeliver Error ERROR ::= ! 

PARAMETER SEQUENCE! 

failureCause FailureCause, 

protocolldentifier [0] IMPLICIT Protocolldentifier OPTIONAL, 

userData [1] IMPLICIT UserData OPTIONAL, 

scAddressSaved [2] IMPLICIT BOOLEAN DEFAULT FALSE } 
CODE local: 1026} 

smsSubmitError ERROR ::= ! 

PARAMETER SEQUENCE! 

failureCause FailureCause, 

serviceCentreTimeStamp ServiceCentreTimeStamp, 

protocolldentifier [0] IMPLICIT Protocolldentifier OPTIONAL, userData 

[1] IMPLICIT UserData OPTIONAL} CODE local: 1027} 
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Table 1 : Operations in Support of SIVIS (concluded) 



smsStatusReportError ERROR ::={ 
PARAMETER SEQUENCE! 

failureCause FailureCause, 

protocolldentifier [0] IMPLICIT Protocolldentifier OPTIONAL, 

userData [ 1 ] IMPLICIT UserData OPTIONAL, 

scAddressSaved [2] IMPLICIT BOOLEAN DEFAULT FALSE } CODE local: 

1028} 

smsCommandError ERROR ::={ 

PARAMETER SEQUENCE! 

failureCause FailureCause, 

serviceCentreTimeStamp ServiceCentreTimeStamp, 

protocolldentifier [0] IMPLICIT Protocolldentifier OPTIONAL, 

userData [1] IMPLICIT UserData OPTIONAL} 

CODE local: 1029} 

unspecified ERROR ::={ 

PARAMETER SmsExtension 
CODE local: 1008} 

END — of Short-Message-Service-Operations-asnl-97 



6.3.2 Information Elements 

6.3.2.1 Facility information element 

The operations defined in clause 6.3.1 for the support of SMS shall be coded in the Facility information element in 
accordance with ECMA-165. 

When conveying the invoke APDU of the operations defined in clause 6.3.1 the destinationEntity data element of the 
NFE shall contain value endPINX. The Interpretation APDU in the Facility information element shall be omitted or 
have the value "rejectAnyUnrecognizedlnvokeAPDU (0)". 

6.3.2.2 Other information elements 

Any other information elements shall be coded in accordance with ECMA-143. 

6.3.3 Messages 

The Facility information element shall be conveyed in messages as specified in clause 10 of ECMA-165. 

6.4 SMS State definitions 

6.4.1 States at the Sending User PINX and at the Sending User Message 
Centre 

The procedures at the Sending User PINX/Sending User Message Centre are written in terms of the following 
conceptual states existing within the SMS control entity in that Sending User PINX/Sending User Message Centre in 
association with a particular request fi"om the Sending User. 

6.4.1.1 SMS-Send-ldle 

SMS is not operating. 
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6.4.1.2 SMS-Send-Submit-Wait 



An smsSubmit invoke APDU has been sent to the Service Centre. The Sending User PINX/Sending User Message 
Centre is waiting for a response. 

6.4.1.3 SMS-Send-Command-Wait 

The Sending User-PINX/Sending User Message Centre has received a command request from the Sending User, has 
sent an smsCommand invoke APDU to the Service Centre and is waiting for receipt of an smsCommand return result, 
return error or reject APDU. 

6.4.2 States at a Service Centre 

The procedures at the Service Centre are written in terms of the following conceptual states existing within the SMS 
control entity in that Service Centre. 

6.4.2.1 States for Short Message Transfer 

6.4.2.1.1 SMS-SC-ldle 

SMS is not operating. 

6.4.2.1.2 SMS-SC-Deliver-Wait 

The Service Centre has sent an smsDeliver invoke APDU to the Receiving User PINX and is waiting for receipt of an 
smsDeliver return result, return error or reject APDU. 

6.4.2.1.3 SMS-SC-Await-Alert 

The Service Centre has received an smsDeliver return error APDU with failureCause "memoryCapacityExceeded" or 
"simSmsStorageFuU" or with an additional Cause Information Element and is now waiting for receipt of an scAlert 
invoke APDU from the Receiving User PINX. 

6.4.2.2 States for Status Report Transfer 

The following states exist in parallel and independently of other states in the Service Centre, if the procedures for Status 
Report are supported. 

6.4.2.2.1 SMS-SC-SR-Wait 

The Service Centre has sent an smsStatusReport invoke APDU to the Sending User PINX/Sending User Message 
Centre and is waiting for receipt of an smsStatusReport return result, return error or reject APDU. 

6.4.2.2.2 SMS-SC-SR-ldle 

The Service Centre is waiting for an internal request to send a Status Report. 

6.4.3 States at a Receiving User PINX 

The procedures at the Receiving User PINX are written in terms of the following conceptual states existing within the 
SMS control entity in that PINX. 

6.4.3.1 SMS-Rec-User-case-ldle 

SMS is not operating. 
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6.4.3.2 SMS-Rec-User-case-AlertWait 

The Receiving User PINX unsuccessfully attempted to deliver a Short Message to a terminal and is waiting for an 
internal indication that the Receiving User is available again for further smsDeliver invoke APDUs. 

6.4.3.3 SMS-Rec-User-case-AlertResp 

The Receiving User PINX has sent an scAlert invoke APDU to the Service Centre and is now waiting for receipt of an 
scAlert return result, return error or reject APDU from the Service Centre. 

6.4.3.4 SMS-Rec-MC-case-ldle 

The Receiving User PINX is waiting to forward received APDUs from the Service to the Receiving User Message 
Centre and vice versa. This state is maintained as long as SMS is provided in the Message Centre Case to the Receiving 
User. 

6.4.4 States at a Receiving User IVIessage Centre 

The procedures at the Sending User Message Centre are written in terms of the following conceptual states existing 
within the SMS control entity in that Message Centre. 

6.4.4.1 SMS-Rec-MC-ldle 

SMS is not operating. 

6.4.4.2 SMS-Rec-MC-AlertWait 

The Message Centre has unsuccessfully attempted to save a Short Message, has sent an smsDeliver return error APDU 
to the Receiving User PINX and is waiting for an internal indication that memory is available again. 

6.4.4.3 SMS-Rec-MC-AlertResp 

The Message Centre has sent an scAlert invoke APDU to the Receiving User PINX and is waiting for receipt of an 
scAlert return result, return error or reject APDU from the Receiving User PINX. 

6.5 SMS signalling procedures 

References in this clause to protocol states refer to protocol states defined in clause 7.3 of ECMA-165. 
The APDU elements referred to in the following subclauses are described in annex E. 

6.5.1 Actions at a Sending User PINX/Sending User IVIessage Centre 

All invoke, return error, return result and reject APDUs shall be transported using the Call Reference of Call 
Independent Signalling Connections (CISC). Therefore the Sending User PINX/Sending User Message Centre shall set 
up a call independent signalling connection in accordance with the procedures described in clause 7.3 in ECMA-165. 
The Sending User PINX/Sending User Message Centre is responsible for the clearing of this call independent signalling 
connection. 
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6.5.1.1 Normal procedures 

6.5.1.1.1 Short Message 

In state SMS-Send-Idle upon request of the Sending User to send a Short Message the Sending User PINX/Sending 
User Message Centre shall; 

• check if the Sending User is permitted to use the SMS; if so 

• generate an smsSubmit invoke APDU, based on the Short Message elements received from the Sending User, 
which shall include the following mandatory elements: 

the PartyNumber of the Receiving User in element destinationAddress; 

the PartyNumber of the Sending User in element originating Address; 

a Message Reference in element messageReference which is allocated by the Sending User PINX/Sending 
User Message Centre for each new Short Message or Command that is sent (see annex E for further details); 

Short Message specific parameters in element smsSubmitParameters (see annex E for further details); 

the Short Message Text and related information in element userData (see annex E for further details); 

• send the smsSubmit invoke APDU to the Service Centre; 

• start timer Tl and enter state SMS-Send-Submit-Wait. 

On receipt in state SMS-Send-Submit-Wait of an smsSubmit return result APDU the Sending User PINX shall 

• stop timer Tl; 

• send an indication to the Sending User that the submission of the Short Message was successful and 

• enter state SMS-Send-Idle. 

6.5.1.1.2 Command 

On request in state SMS-Send-Idle of the Sending User to send a Command the Sending User PINX/Sending User 
Message Centre shall: 

• check if the Sending User is permitted to use the SMS, if so 

• generate an smsCommand invoke APDU based on the Command information received from the Sending User, 
which shall include the following elements: 

the PartyNumber of the Receiving User of the Short Message to which the Command refers in element 
destinationAddress; 

a Message Reference in element messageReference which is allocated by the Sending User PINX/Sending 
User Message Centre for each new Short Message or Command that is sent (see annex E for further details); 

the Message Reference of the Short Message to which the Command refers in element messageNumber; 

the Protocol Identifier identifying the higher layer protocol in element protocolldentifier (see annex E for 
further details); 

the Command Type in element commandType (see annex E for further details); 

optional elements as described in annex E. 

• send the smsCommand invoke APDU to the Service Centre; 

• start timer T2 and enter state SMS-Send-Command-Wait. 
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On receipt in state SMS-Send-Command-Wait of an smsCommand return result APDU the 
Sending User PINX/Sending User Message Centre shall; 

• stop timer T2; 

• send an indication to the Sending User that the submission of the Command was successful and 

• enter state SMS-Send-Idle. 

6.5.1.1.3 Status Report 

On receipt in state SMS-Send-Idle of an smsStatusReport invoke APDU the 
Sending User PINX/Sending User Message Centre shall: 

• indicate the content of the received smsStatusReport invoke APDU to the Sending User; 

• send an smsStatusReport return result APDU (see annex E) to the Service Centre and 

• enter state SMS-Send-Idle. 

6.5.1.2 Exceptional procedures 

In state SMS-Send-Idle upon a request from the Sending User to submit a Short Message or a Command, the 
Sending User PINX/Sending User Message Centre shall return an error indication to the Sending User if; 

• the Sending User is not permitted to use the SMS; 

• the smsSubmit/smsCommand elements are incorrect or if mandatory elements are missing. 

6.5.1.2.1 Short Message 

On receipt in state SMS-Send-Submit-Wait of an smsSubmit reject or return error APDU the Sending User 
PINX/Sending User Message Centre shall: 

• stop timer Tl; 

• send an indication including the error reason to the Sending User and 

• enter state SMS-Send-Idle. 

On expiry of timer Tl in state SMS-Send-Submit-Wait the Sending User PINX/Sending User Message Centre shall 
either 

re-send the smsSubmit invoke APDU, start timer Tl and re-enter state SMS-Send-Submit-Wait or 

send an indication including the error reason to the Sending User and enter state SMS-Send-Idle. 

NOTE: The number of times the Sending User PINX may repeat the smsSubmit is an implementation matter. 

6.5.1.2.2 Command 

On receipt in state SMS-Send-Command-Wait of an smsCommand reject or return error APDU the Sending User 
PINX/Sending User Message Centre shall: 

• stop timer T2; 

• send an indication including the error reason to the Sending User and 

• enter state SMS-Send-Idle. 
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On expiry of timer T2 in state SMS-Send-Command-Wait the Sending User PINX/Sending User Message Centre shall 
either: 

re-send the smsCommand invoke APDU, start timer T2 and re-enter state SMS-Send-Command-Wait or 

send an indication including the error reason to the Sending User and enter state SMS-Send-Idle. 

NOTE: The number of times the Sending User PINX may repeat the smsCommand is an implementation matter. 

6.5.1.2.3 Status Report 

On receipt in state SMS-Send-Idle of an smsStatusReport invoke APDU the Sending User PINX/Sending User Message 
Centre shall in case of an error send an smsStatusReport return error APDU with an appropriate error indication in 
element failureCause, to the Service Centre and enter state SMS-Send-Idle. Elements of the smsStatusReport error 
APDU and specific error reasons and related failureCause values are described in annex E. 

6.5.2 Actions at a Sending User IVIessage Centre 

The procedures for the Sending User Message Centre are as described in clause 6.5.1. 

6.5.3 Actions at a Service Centre 

All invoke, return error, return result and reject APDUs shall be transported using the Call Reference of Call 
Independent Signalling Connections (CISC). Therefore the Service Centre shall set up a call independent signalling 
connection in accordance with the procedures described in clause 7.3 in ECMA-165. The Service Centre is responsible 
for the clearing of this call independent signalling connection. 

6.5.3.1 Normal procedures 

6.5.3.1.1 Short Message 

On receipt in state SMS-SC-Idle of an smsSubmit invoke APDU from the Sending User PINX/Sending User Message 
Centre the Service Centre shall check if the received smsSubmit invoke APDU contains a Short Message with the same 
messageReference and destinationAddress as a previously received Short Message from the same originatingAddress. 

In case such a Short Message exists and the rejectDuplicates APDU element is set to FALSE or in case that the 
messageReference is different to the messageReference of the previously received Short Message the Service Centre 
shall: 

• check the APDU element protocolldentifier and 

if it is set to "replaceShortMessage" check the originatingAddress and replace any existing stored Short 
Message having the same Protocol Identifier Code and originatingAddress with the new Short Message and 
other parameter values. If there is no message to be replaced the Service Centre shall store the Short Message 
in the normal way; 

if no "replaceShortMessage" code is present the Service Centre shall store the Short Message locally; 

• analyse and store the smsSubmit invoke APDU; 

• set the internal value StatusReportRequest according to the statusReportRequest element and the 
smscControlParameterHeader as received in the smsSubmit invoke APDU; if the smscControlParameterHeader 
was not received it shall be assumed that all values of this element are set to TRUE (i.e. a Status Report is 
requested for all conditions); 

• assign and store a serviceCentreTimeStamp and the priority (see annex E) for the Short Message; 
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• send an smsSubmit return result APDU to the Sending User PINX/Sending User Message Centre with the 
following elements (see annex E for further details): 

serviceCentreTimeStamp; 

further optional elements as described in annex E; 

• send an smsDeliver invoke APDU to the Receiving User PINX containing the received elements from the 
smsSubmit invoke APDU and the following additional elements (see annex E for further details): 

optionally, the originatingName of the Sending User if available and not restricted; 

serviceCentreTimeStamp as designed by the Service Centre; 

- priority as assigned by the Service Centre; 

moreMessagesToSend: set to TRUE if there are more Short Messages waiting in that Service Centre for that 
particular destinationAddress; 

statusReportlndication: set to TRUE if the statusReportRequest information element was set to TRUE in the 
original smsSubmit invoke APDU; 

- replyPath: set to TRUE if the Service Centre supports the Reply Path functionality; 

• start timer T3 and enter state SMS-SC-Deliver-Wait. 

On receipt in state SMS-SC-Deliver-Wait of an smsDeliver return result APDU the Service Centre shall: 

• stop timer T3; 

• generate an internal request to send a Status Report with value "smReceivedBySME" if the internal 
StatusReportRequest field is set for this condition and 

• enter state SMS-SC-Idle. 

6.5.3.1.2 Command 

On receipt in any state except SMS-SC-Idle of an smsCommand invoke APDU the Service Centre shall: 

• identify a specific locally stored Short Message by the received smsCommand invoke APDU elements 

originatingAddress; 

messageNumber, containing the messageReference of the stored Short Message; 

• execute the requested commandType on this message, i.e. for commandType: 

"Enquiry" generate an internal request to send a Status Report, regardless of the setting of the internal 
StatusReportRequest field; 

"CancelSRR" set the internal field StatusReportRequest to FALSE for all conditions; 

"EnableSRRrelatingToPreviouslySubmittedSM" set the internal field StatusReportRequest to TRUE for all 
conditions; 

"DeletePreviouslySubmittedSM" delete the identified Short Message and generate an internal request to send 
a Status Report with value "smDeletedByOriginatingSME" if the internal StatusReportRequest field is set for 
this condition; 

• afterwards, send an smsCommand return result APDU to the Sending User PINX/Sending User Message Centre 
and re-enter the current state. 
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6.5.3.1.3 Status-Report 



NOTE: The Status Report-related procedures within the Service Centre are independent of those for the normal 
Short Message. 

In state SMS-SC-SR-Idle on an internal request to send a Status Report for a specific Short Message the Service Centre 
shall send an smsStatusReport invoke APDU to the Sending User PINX/Sending User Message Centre using the 
following smsStatusReport APDU elements: 

• messageReference: value contained in the previously received smsSubmit or smsCommand invoke APDU. If the 
Status Report is the result of an smsCommand where commandType was "Enquiry" the messageReference used 
in the Status Report shall be the messageNumber contained in the smsCommand invoke APDU (i.e. the 
messageReference of the previously submitted Short Message to which the "Enquiry" refers). 

• dischargeTime: time at which a previously submitted smsSubmit invoke APDU was successfully delivered to or 
attempted to deliver to the Receiving User or disposed of by the SC; 

• serviceCentreTimeStamp: the serviceCentreTimeStamp assigned to the original smsSubmit invoke APDU; 

and other elements as described in clause 6.3.1, start timer T5 and enter state SMS-SC-SR-Wait. 

On receipt in state SMS-SC-SR-Wait of an smsStatusReport return result APDU from the Sending User PINX/Sending 
User Message Centre the Service Centre shall stop timer T5 and enter state SMS-SC-SR-Idle. 

6.5.3.2 Exceptional procedures 

6.5.3.2.1 Short Message 

For a general description of all possible error values and their usage refer to annex E. 

On receipt in state SMS-SC-Idle of an smsSubmit invoke APDU from the Sending User PINX/Sending User Message 
Centre and this APDU contains 

• either element rejectDuplicates set to TRUE and messageReference and destinationAddress of a previously 
received Short Message from the same originatingAddress; 

• or element messageReference that is identical to the messageReference of a previously received Short Message 
from the same Sending User, but indicates a different destinationAddress; 

• the Service Centre shall send an smsSubmit return error APDU to the Sending User PINX/Sending User 
Message Centre with failureCause "smRejectedDuplicateSM", discard the smsSubmit invoke APDU and enter 
state SMS-SC-Idle. 

If element protocolldentifier of the received smsSubmit invoke APDU indicates a specific interworking and if 
interworking is not supported by the Service Centre it shall return an smsSubmit return error APDU with failureCause 
"telematicInterworkingNotSupported" and enter state SMS-SC-Idle. 

On receipt in state SMS-SC-Deliver-Wait of an smsDeliver return error APDU from the Receiving User PINX the 
Service Centre shall check the APDU element failureCause. 

If it contains the value "memoryCapacityExceeded" or "simSmsStorageFull" or if an additional Cause Information 
Element has been received, the Service Centre shall: 

• stop timer T3; 

• generate an internal request to send a Status Report with value "errorlnSme" if the internal StatusReportRequest 
field is set for this condition; 

• start timer T4 if the smsDeliver return error APDU element scAddressSaved is set to FALSE (i.e. the Receiving 
User PINX will not send an scAlert invoke APDU if the smsDeliver invoke APDU can be re-sent) and 

• enter state SMS-SC-Await- Alert. 
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If a different failureCause was received, the Service Centre shall: 

• stop timer T3; 

• delete the Short Message; 

• generate an internal request to send a Status Report with an appropriate value if the internal StatusReportRequest 
field is set for this condition and 

• enter state SMS-SC-Idle. 

On receipt in state SMS-SC-Deliver-Wait of an smsDeliver reject APDU the Service Centre shall: 

• stop timer T3; 

• delete the Short Message; 

• generate an internal request to send a Status Report with value "connectionRejectedBySME" if the internal 
StatusReportRequest field is set for this condition and 

• enter state SMS-SC-Idle. 

On expiry of timer T3 in state SMS-SC-Deliver-Wait the Service Centre may: 

• either re-send the smsDeliver invoke APDU to the Receiving User PINX, start timer T3, generate an internal 
request to send a Status Report with value "noResponseFromSME" if the internal StatusReportRequest field is 
set for this condition and re-enter state SMS-SC-Deliver-Wait or 

• delete the Short Message, generate an internal request to send a Status Report with value 
"smDeletedByScAdministration" if the internal StatusReportRequest field is set for this condition and enter state 
SMS-SC-Idle. 

On receipt in state SMS-SC-Await- Alert of an scAlert invoke APDU from the Receiving User PINX the Service Centre 
shall stop timer T4 if running, check the scAlert invoke APDU and depending on the outcome send an scAlert return 
result or return error APDU to the Receiving User PINX. If the scAlert is valid the SC shall: 

• send the smsDeliver invoke APDU to the Receiving User PINX of the user whose number was contained in the 
scAlert invoke APDU; 

• start timer T3 and 

• enter state SMS-SC-Deliver-Wait. 

On expiry of timer T4 in state SMS-SC-Await- Alert the Service Centre shall: 

• send the smsDeliver invoke APDU to the Receiving User PINX; 

• start timer T3 and 

• enter state SMS-SC-Deliver-Wait. 

NOTE: The number of times the Service Centre may repeat the delivery attempt for a Short Message depends on 
the duration of timer T4 and the Validity Period for this Short Message. If no Validity Period was 
indicated by the Sending User, an SC-specific default value will be assumed. 

On receipt in state SMS-SC-Await- Alert of an internal indication that the Validity Period for a Short Message expired 
the Service Centre shall stop timer T4 if running and shall either: 



• 



once again re-send the smsDeliver invoke APDU to the Receiving User PINX with priority set to TRUE, start 
Timer T3 and enter state SMS-SC-Deliver-Wait or 

delete the Short Message, generate an internal request to send a Status Report with value 
"smValidityPeriodExpired" if the internal StatusReportRequest field is set for this condition and enter state 
SMS-SC-Idle. 
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On receipt in state SMS-SC-Deliver-Wait of an smsDeliver return error or return reject APDU for a Short Message for 
which the Vahdity Period has aheady expired, the Service Centre shall stop Timer T3 and generate an internal request 
to send a Status Report with value "smValidityPeriodExpired" if the internal StatusReportRequest field is set for this 
condition and enter state SMS-SC-Idle. 

6.5.3.2.2 Command 

On receipt in any state of an smsCommand invoke APDU, if no Short Message can be identified, the Service Centre 
shall: 

• return an smsCommand return error APDU to the Sending User PINX/Sending User Message Centre with 
failureCause "commandCannotBeActioned" ; 

• generate an internal request to send a Status Report with value "smDoesNotExist" if the internal 
StatusReportRequest field is set for this condition and 

• re-enter the current state. 

6.5.3.2.3 Status Report 

On receipt in state SMS-SC-SR-Wait of an smsStatusReport return error APDU or an smsStatusReport reject APDU or 
on expiry of timer T5 the Service Centre shall stop timer T5 (if running) and enter the SMS-SC-SR-Idle and may 
afterwards re-send the smsStatusReport invoke APDU according to the procedures described in clause 6.5.3.1.1. 

6.5.4 Actions at a Receiving User PINX 

All invoke, return error, return result and reject APDUs shall be transported using the Call Reference of Call 
Independent Signalling Connections (CISC). Therefore the Receiving User PINX shall set up a call independent 
signalling connection in accordance with the procedures described in clause 7.3 in ECMA-165. The Receiving User 
PINX is responsible for the clearing of this call independent signalling connection. 

Due to internal administration, the Receiving User PINX shall, upon starting operation for a specific user, either 

• enter state SM-Rec-MC-case-Idle if the Short Messages are stored and managed at the Receiving User Message 
Centre or 

• enter state SM-Rec-User-case-Idle if the Short Messages are stored and managed locally, either by the Receiving 
Users terminal equipment or by the Receiving User PINX. 

6.5.4.1 Normal procedures 

In state SM-Rec-MC-case-Idle upon receipt of an smsDeliver return result, reject, return error APDU or an scAlert 
invoke APDU from the Receiving User Message Centre the Receiving User PINX shall send these APDUs to the 
Service Centre. 

In state SM-Rec-MC-case Idle upon receipt of an smsDeliver invoke APDU, an scAlert return result, return error or 
reject APDU the Receiving User PINX shall send these APDUs to the Receiving User Message Centre. 

On receipt in state SMS-Rec-User-case-Idle of an smsDeliver invoke APDU from the Service Centre the Receiving 
User PINX shall attempt to deliver the SM to the Receiving User. If the SM can successfully be delivered the Receiving 
User PINX shall send an smsDeliver return result APDU to the Service Centre and enter state SMS-Rec-User-case-Idle. 
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6.5.4.2 Exceptional procedures 



In state SMS-Rec-User-case-Idle, if element protocolldentifier of the received smsDeliver invoke APDU is set to 
"shortMessageTypeO" the Receiving User PINX shall send an smsDeliver return result APDU to the Service Centre but 
may discard its contents due to internal configuration or restrictions of the Receiving Users terminal equipment. 

If the attempt by the Receiving User PINX to deliver a Short Message received from the Service Centre to the 
Receiving User is not successful, the Receiving User PINX shall 

if SMWD is not implemented; 

• send to the Service Centre an smsDeliver return error APDU with the following elements: 

failureCause set to "memoryCapacityExceeded" or "simSmsStorageFuU"; 
optionally protocolldentifier as received in the original smsDeliver invoke APDU; 
optionally userData as received in the original smsDeliver invoke APDU; 
scAddressSaved set to FALSE and 

• enter state SMS-Rec-User-case-Idle. 

if SMWD is implemented; 

• save the Service Centre Address as indicated in the CallingPartyNumber Information Element of the 
call-independent-signalling-connection on which the smsDeliver invoke APDU was received, if not saved 
already; 

• send to the Service Centre an smsDeliver return error APDU with the following elements: 

failureCause set to "memoryCapacityExceeded" or "simSmsStorageFuU"; 
optionally protocolldentifier as received in the smsDeliver invoke APDU; 
optionally userData as received in the smsDeliver invoke APDU; 
scAddressSaved set to TRUE and 

• enter state SMS-Rec-User-case-AlertWait. 

On receipt in state SMS-Rec-User-case-AlertWait of an internal indication that the user is reachable or that the user has 
memory available again the Receiving User PINX shall send an scAlert invoke APDU to all Service Centres which are 
stored in the SMWD, start timer T6 and enter state SMS-Rec-User-case-AlertResp for each of the sent scAlert invoke 
APDUs. 

On receipt in state SMS-Rec-User-case-AlertWait of an smsDeliver invoke APDU with element priority set to TRUE 
the Receiving User PINX shall attempt to deliver the SM to the Receiving User. 

If the SM can be delivered the Receiving User PINX shall: 

• return an smsDeliver return result APDU to the Service Centre as described in clause 6.5.4.1; 

• send an scAlert invoke APDU with element originatingAddress set to the Party Number of the Receiving User 
for all Service Centres that are contained in the SMWD to the Service Centres; 

• start timer T6 and enter state SMS-Rec-User-case-Alert-Resp. 

If the SM can not be delivered then, if the SC Address is not yet stored in SMWD, the SC Address as indicated in the 
CallingPartyNumber Information element of the call-independent-signalling-connection shall be saved in SMWD and 
the Receiving User PINX shall send an smsDeliver return error APDU to the Service Centre with scAddressSaved set to 
TRUE (see above). 
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On receipt in state SMS-Rec-User-case-AlertWait of an smsDeliver invoke APDU the Receiving User PINX shall: 

• if the SC Address is not saved already in SMWD, save it there; 

• return an smsDeliver return error APDU to the Service Centre with scAddressSaved set to TRUE (see above) 
and 

• re-enter state SMS-Rec-User-case-AlertWait. 

On receipt in state SMS-Rec-User-case-AlertResp of an scAlert return result APDU the Receiving User PINX shall 
delete the address of the SC from the SMWD, stop timer T6 and enter state SMS-Rec-User-case-Idle. 

On receipt in state SMS-Rec-User-case-AlertResp of an scAlert return error or reject APDU or upon expiry of timer T6, 
the Receiving User PINX shall stop timer T6 (if running) and shall: 

• either delete the address of the SC fi^om the SMWD and enter state SMS-Rec-User-case-Idle; 

• or re-send the scAlert invoke APDU to the Service Centre, start timer T6 and re-enter state 
SMS-Rec-User-case-AlertResp. 

On receipt in state SMS-Rec-User-case-AlertResp of an smsDeliver invoke APDU from the SC, the Receiving User 
PINX shall treat this APDU as described in clause 6.5.4.1 but shall not enter state SMS-Rec-User-case-Idle but re-enter 
SMS-Rec-User-case-AlertResp instead. Timer T6 shall not be stopped in this case. 

NOTE: The number of times the Receiving User PINX may repeat the scAlert is an implementation matter. 

6.5.5 Actions at a Receiving User Message Centre 

All invoke, return error, return result and reject APDUs shall be transported using the Call Reference of Call 
Independent Signalling Connections (CISC). Therefore the Receiving User Message Centre shall set up a call 
independent signalling connection in accordance with the procedures described in clause 7.3 in ECMA-165. The 
Receiving User Message Centre is responsible for the clearing of this call independent signalling connection. 

6.5.5.1 Normal procedures 

On receipt in state SMS-Rec-MC-Idle of an smsDeliver invoke APDU from the Receiving User PINX the Receiving 
User Message Centre shall check the APDU element protocolldentifier. If it is set to 

• "shortMessageTypeO" the Receiving User Message Centre shall perform the procedures as described for this 
case in clause 6.5.4.2. 

• "replaceShortMessage" the Receiving User Message Centre shall perform the procedures as described for the 
"replaceShortMessage" value in the protocolldentifier in clause 6.5.3.2. 

If the Short Message is saved the Receiving User Message Centre shall send an smsDeliver return result APDU to the 
Sending User PINX, indicate the reception of a new Short Message to the Receiving User using SS-MWI and enter 
state SMS-Rec-MC-Idle. 

6.5.5.2 Exceptional procedures 

In state SMS-Rec-MC-Idle, if element protocolldentifier of the received smsDeliver invoke APDU is set to 
"shortMessageTypeO" the Receiving User Message Centre shall send an smsDeliver return result APDU to the 
Receiving User PINX but may discard its contents due to internal configuration or restrictions of the Receiving User 
Message Centre. 
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On receipt in state SMS-Rec-MC-Idle of an smsDeliver invoke APDU from the Receiving User PINX if it is not 
possible for the Receiving User Message Centre to save the SM it shall: 

if SMWD is implemented, 

• save the Service Centre address as indicated in the CallingPartyNumber Information element of the 
call-independent-signalling-connection on which the smsDeliver invoke APDU was received, if not saved 
already; 

• send an smsDeliver return error APDU to the Service Centre with the following elements: 

failureCause "memoryCapacityExceeded"; 

optionally protocolldentifier as received in the original smsDeliver invoke APDU; 
optionally userData as received in the original smsDeliver invoke APDU; 
scAddressStored set to TRUE and 

• enter state SMS-Rec-MC-AlertWait; 

if SMWD is not implemented; 

• send an smsDeliver return error APDU to the Receiving User PINX with the following elements: 

failureCause set to "memoryCapacityExceeded"; 

optionally protocolldentifier as received in the original smsDeliver invoke APDU; 
optionally userData as received in the original smsDeliver invoke APDU; 
scAddressStored set to FALSE and 

• enter state SMS-Rec-MC-Idle. 

On receipt in state SMS-Rec-MC-AlertWait of an internal indication that the user is reachable or that the user has 
memory available again the Receiving User Message Centre shall send an scAlert invoke APDU to all Service Centres 
which are stored in the SMWD, start timer T7 and enter state SMS-Rec-MC-AlertResp for each of the sent scAlert 
invoke APDUs. 

On receipt in state SMS-Rec-MC-AlertWait of an smsDeliver invoke APDU with element priority set to TRUE the 
Receiving User Message Centre shall attempt to save the SM, following the procedures described in clause 6.5.5.1. If 
the SM can be saved the Receiving User Message Centre shall: 

• return an smsDeliver return result APDU to the Receiving User PINX as described in clause 6.5.5.1; 

• send an scAlert invoke APDU to the Receiving User PINX with element originatingAddress set to the Party 
Number of the Receiving User for all Service Centres which are stored in the SMWD; 

• start timer T7 and enter state SMS-Rec-MC-AlertResp. 

If the SM can not be saved then, if the SC Address is not yet stored in SMWD, the SC address as indicated in the 
CallingPartyNumber Information element of the call-independent-signalling-connection shall be saved in SMWD, the 
Receiving User Message Centre shall send an smsDeliver return error APDU to the Receiving User PINX with 
scAddressStored set to TRUE and enter state SMS-Rec-MC-AlertWait. 

On receipt in state SMS-Rec-MC-AlertWait of an smsDeliver invoke APDU the Receiving User Message Centre shall 

• if the SC Address is not saved already in SMWD save it there; 

• return an smsDeliver return error APDU with failureCause "memoryCapacityExceeded" and with 
scAddressStored set to TRUE to the Receiving User PINX and 

• re-enter state SMS-Rec-MC-AlertWait. 
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On receipt in state SMS-Rec-MC-AlertResp of an scAlert return result APDU or upon expiry of timer T7 the Receiving 
User Message Centre shall stop timer T7 (if running), delete the SC Address from the SMWD field and enter state 
SMS-Rec-MC-Idle. 

On receipt in state SMS-Rec-MC-AlertResp of an scAlert return error or reject APDU the Receiving User Message 
Centre shall stop timer T7 (if running) and shall: 

• either delete the address of the SC from the SMWD and enter state SMS-Rec-MC-Idle; 

• or re-send the scAlert invoke APDU to the Service Centre, start timer T7 and re-enter state 
SMS-Rec-MC-AlertResp. 

On receipt in state SMS-Rec-MC-AlertResp of an smsDeliver invoke APDU from the Receiving User PINX the 
Receiving User Message Centre shall treat this APDU as described in clause 6.5.5.1 but shall not enter state 
SMS-Rec-MC-Idle but re-enter SMS-Rec-MC-AlertResp instead. Timer T7 shall not be stopped in this case. 

NOTE: The number of times the Receiving User Message Centre may repeat the scAlert is an implementation 
matter. 

6.6 SMS impact on interworking with public ISDNs 

NOTE: The interworking with the GSM network is described in annex D. 

6.7 SIVIS impact on interworking with non-ISDNs 

Not applicable. 

6.8 Protocol Interactions between SMS and supplementary 
services and ANFs 

This clause specifies protocol interactions with supplementary services and ANFs for which stage 3 standards had been 
published at the time of publication of the present document. For interactions with supplementary services and ANFs 
for which stage 3 standards are published subsequent to the publication of the present document, see those other stage 3 
standards. 

NOTE 1 : Simultaneous conveyance of APDUs for SMS and supplementary service or ANF in the same message, 
each in accordance with the requirements of its respective stage 3 standard, does not, on its own, 
constitute a protocol interaction. 

NOTE 2: Additional interactions that have no impact on the signalling protocol at the Q reference point can be 
found in the relevant stage 1 specification. 

6.8.1 Calling Line Identification Presentation (SS-CLIP) 

No protocol interaction. 

6.8.2 Connected Line Identification Presentation (SS-COLP) 

No protocol interaction. 

6.8.3 Calling/Connected Line Identification Restriction (SS-CLIR) 

No protocol interaction. 

6.8.4 Calling Name Identification Presentation (SS-CNIP) 

No protocol interaction. 
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6.8.5 Calling/Connected Name Identification Restriction (SS-CNIR) 

No protocol interaction. 

6.8.6 Connected Name Identification Presentation (SS-CONP) 

No protocol interaction. 

6.8.7 Completion of Calls to Busy Subscriber (SS-CCBS) 

No protocol interaction. 

6.8.8 Completion of Calls on No Reply (SS-CCNR) 

No protocol interaction. 

6.8.9 Call Transfer (CT) 

No protocol interaction. 

6.8.10 Call Forwarding Unconditional (SS-CFU) 

No protocol interaction. 

6.8. 11 Call Forwarding Busy (SS-CFB) 

No protocol interaction. 

6.8.12 Call Forwarding No Reply (SS-CFNR) 

No protocol interaction. 

6.8. 13 Call Deflection (SS-CD) 

No protocol interaction. 

6.8.14 Path Replacement (ANF-PR) 

No protocol interaction. 

6.8.15 Call Offer (SS-CO) 

No protocol interaction. 

6.8.16 Call Intrusion (SS-CI) 

No protocol interaction. 

6.8.17 Do Not Disturb (SS-DND) 

No protocol interaction. 

6.8.18 Do Not Disturb Override (SS-DNDO) 

No protocol interaction. 
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6.8. 1 9 Advice of charge (SS-AOC) 

No protocol interaction. 

6.8.20 Recall (SS-RE) 

No protocol interaction. 

6.8.21 Call Interception (ANF-CINT) 

No protocol interaction. 

6.8.22 Transit Counter (ANF-TC) 

No protocol interaction. 

6.8.23 Route Restriction Class (ANF-RRC) 

No protocol interaction. 

6.8.24 Message Waiting Indication (SS-MWI) 

The Receiving User Message Centre shall, upon receipt and storage of an smsDeliver invoke APDU, send an 
mwi Activate invoke APDU with element basicService set to "shortMessageService" to the Receiving User PINX. 

6.8.25 Cordless Terminal Location Registration (SS-CTLR) 

No protocol interaction. 

6.8.26 Cordless Terminal Mobility Incoming Call (SS-CTMI) 

No protocol interaction. 

6.8.27 Cordless Terminal Mobility Outgoing Call (SS-CTMO) 

No protocol interaction. 

6.8.28 Authentication of a CTM user (SS-CTAT) 

No protocol interaction. 

6.8.29 Authentication of the PISN (SS-CTAN) 

No protocol interaction. 

6.8.30 Private User Mobility Incoming Call (ANF-PUMI) 

No protocol interaction. 

6.8.31 Private User Mobility Outgoing Call (ANF-PUMO) 

No protocol interaction. 
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6.8.32 Private User Mobility Registration (SS-PUIVIR) 

No protocol interaction. 

6.8.33 Common information (ANF-CiVIN) 

No protocol interaction. 

6.8.34 Caii Priority Interruption (Protection) (SS-CPI(P)) 

No protocol interaction. 

6.8.35 Single Step Call Transfer (SS-SSCT) 

No protocol interaction. 

6.8.36 Simple Dialog (SS-SD) 

No protocol interaction. 

6.8.37 Call Identification and Call Linkage (ANF-CIDL) 

No protocol interaction. 

6.9 SS-SMS Parameter values (Timers) 

6.9.1 Timer T1 

Timer Tl shall operate at the Sending User PINX during state SMS-Send-Submit-Wait. Its purpose is to protect against 
an absence of response to smsSubmit invoke APDU. 

Timer Tl shall have a value in the range of 4 to 6 seconds. 

6.9.2 Timer T2 

Timer T2 shall operate at the Sending User PINX during state SMS-Send-Command-Wait. Its purpose is to protect 
against an absence of response to smsCommand invoke APDU. 

Timer T2 shall have a value in the range of 4 to 6 seconds. 

6.9.3 Timer T3 

Timer T3 shall operate at the Service Centre during state SMS-SC-Deliver-Wait. Its purpose is to protect against 
absence of response to smsDeliver invoke APDU. 

Timer T3 shall have a value in the range of 4 to 6 seconds. 

6.9.4 Timer T4 

Timer T4 may operate optionally at the Service Centre, if Short Message Waiting Data is not implemented, during state 
SMS-SC-Await- Alert. Its purpose is to ensure the automatic repetition of the delivery attempt of a Short Message. 

Timer T4 shall have an implementation dependent value. 
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6.9.5 Timer T5 



Timer T5 shall operate at the Service Centre during state SMS-SC-SR-Wait. Its purpose is to protect against absence of 
response to smsStatusReport invoke APDU. 

Timer T5 shall have a value in the range of 4 to 6 seconds. 

6.9.6 Timer T6 

Timer T6 shall operate at the Receiving User PINX during state SMS-Rec-User-case-AlertResp. Its purpose is to 
protect against an absence of response to scAlert invoke APDU. 

Timer T6 shall have a value in the range of 4 to 6 seconds. 

6.9.7 Timer T7 

Timer T7 shall operate at the Receiving User Message Centre during state SMS-Rec-MC-AlertResp. Its purpose is to 
protect against absence of response to scAlert invoke APDU. 

Timer T7 shall have a value in the range of 4 to 6 seconds. 
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Annex A (normative): 

Protocol Implementation Conformance Statement (PICS) 

Proforma 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the <proformatype> proforma in this {clauselannex) so that it can 
be used for its intended purposes and may further publish the completed <proformatype>. 



A.1 Introduction 

The supplier of a protocol implementation which is claimed to conform to the present document shall complete the 
Protocol Implementation Conformance Statement (PICS) proforma in clause A.3. 

A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of which 
capabilities and options of the protocol have been implemented. The PICS can have a number of uses, including use; 

• by a protocol implementor, as a check list to reduce the risk of failure to conform to the standard through 
oversight; 

• by the supplier and acquirer (or potential acquirer) of the implementation, as a detailed indication of the 
capabilities of the implementation, stated relative to the common basis for understanding provided by the 
standard PICS proforma; 

• by user (or potential user) of the implementation, as a basis for initially checking the possibility of interworking 
with another implementation (note that, while interworking cannot be guaranteed, failure to interwork can often 
be predicted from incompatible PICS); 

• by a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for conformance 
of the implementation. 



A.2 Instructions for completing the PICS proforma 
A.2.1 General structure of the PICS proforma 

The PICS proforma is a fixed format questionnaire divided into subclauses each containing a group of individual items. 
Each item is identified by an item number, the name of the item (question to be answered) and the reference(s) to the 
clause(s) that specifies (specify) the item in the main body of the present document. 

The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The 
following terms are used: 

m mandatory (the capability is required for conformance to the protocol); 

o optional (the capability is not required for conformance to the protocol, but if the capability is 

implemented, it is required to conform to the protocol specifications); 

o.<n> optional, but support of at least one of the group of options labelled by the same numeral <n> is 

required; 

X prohibited; 

c.<cond> conditional requirement, depending on support for the item or items listed in condition <cond>; 

<item>:m simple conditional requirement, the capability being mandatory if item number <item> is 

supported, otherwise not applicable; 
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<item>:o simple conditional requirement, the capability being optional if item number <item> is supported, 

otherwise not applicable. 

Answers to the questionnaire items are to be provided either in the "Support" column, by simply marking an answer to 
indicate a restricted choice (Yes or No) or in the "Not Applicable" column (N/A). 

A.2.2 Additional information 

Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of 
the PICS. It is not intended or expected that a large quantity will be supplied, and a PICS can be considered complete 
without any such information. Examples might be an outline of the ways in which a (single) implementation can be set 
up to operate in a variety of environments and configurations. 

References to items of Additional Information may be entered next to any answer in the questionnaire, and may be 
included in items of Exception information. 



A.2.3 Exceptional information 



It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any 
conditions have been applied) in a way that conflicts with the indicated requirements. No pre-printed answer will be 
found in the Support column for this. Instead, the supplier is required to write into the Support column an x.<i> 
reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. 

An implementation for which an Exception item is required in this way does not conform to the present document. A 
possible reason for the situation described above is that a defect in the Standard has been reported, a correction for 
which is expected to change the requirement not met by the implementation. 



A.3 PICS Proforma for ECMA-325 



A.3.1 Implementation identification 



Supplier 




Contact point for queries about tlie PICS 




Implementation Name(s) and Version(s) 




Other information necessary for full 
identification, e.g. name(s) and version(s) 
for machines and/or operating systems; 
system name(s) 





Only the first three items are required for all implementations; other information may be completed as appropriate in 
meeting the requirement for full identification. 

The terms Name and Version should be interpreted appropriately to correspond with a supplier's terminology (e.g. 
Type, Series, Model). 



A.3. 2 Protocol summary 



Protocol Version 


1.0 


Agenda Implemented 
(if applicable) 




Amendments implemented 




Have any exception items been required 
(see clause A.2.3)? 


No [ ] Yes [ ] 

(The answer Yes means that the implementation does not 

conform to the present document.) 


Date of Statement 
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A.3.3 Short Message Service 



Item 


Name of Item 


Reference 


Status 


N/A 


Support 


A1 


Support of SMS in Sending User PINX 




0.1 




Yes[] No[] 


A2 


Support of SIVIS in Sending IVIessage Centre 




0.1 




Yes[] No[] 


A3 


Support of SIVIS in Service Centre 




0.1 




Yes[] No[] 


A4 


Support of SMS in Receiving User PINX 




0.1 




Yes[] No[] 


A5 


Support of SMS in Receiving Message Centre 




0.1 




Yes[] No[] 



A.3.4 Procedures for SMS 



Item 


Name of Item 


Reference 


Status 


N/A 


Support 


B1 


Procedures at the Sending User PINX 


6.5.1 


A1:m 


[] 


Yes[] 


B2 


Procedures at the Sending Message Centre 


6.5.1 


A2:m 




Yes[] 


B3 


Procedures at the Service Centre 


6.5.3 


A3:m 




Yes[] 


B4 


Procedures at the Receiving User PINX 


6.5.4 


A4:m 




Yes[] 


B5 


Procedures at the Receiving Message Centre 


6.5.5 


A5:m 




Yes[] 


B6 


Procedures for Status Report 


6.5 


C.I 




Yes[] No[] 


B7 


Procedures for Reply Path 


6.5 


C.2 




Yes[] No[] 


B8 


Procedures for Short Message Waiting Data 


6.5 


C.2 




Yes[] No[] 


B9 


Procedures for Concatenated Short Message 


6.5 







Yes[] No[] 


B.10 


Procedures for Validity Period 


6.5 


C.I 




Yes[] No[] 



c. 1 : If B 1 or B2 or B3 then o else N/A 
c.2: If B3 or B4 or B5 then o else N/A 
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A.3.5 Coding 



Item 


Name of Item 


Reference 


Status 


N/A 


Support 


C1 


Sending of smsSubmit invoke APDU and 
receipt of return result and return error APDUs 


6.5.1 


C.3 




Yes[] 


C2 


Sending of smsCommand invoke APDU and 
receipt of return result and return error APDUs 


6.5.1 


C.3 




Yes[] 


C3 


Receipt of smsStatusReport invoke APDU and 
sending of return result and return error APDUs 


6.5.1 


B.6:m 




Yes[] 


C4 


Sending of smsStatusReport invoke APDU and 
receipt of return result and return error APDUs 


6.5.3 


B.6:m 




Yes[] 


C5 


Receipt of smsSubmit invoke APDU and 
sending of return result and return error APDUs 


6.5.3 


B.3:m 




Yes[] 


C6 


Receipt of smsCommand invoke APDU and 
sending of return result and return error APDUs 


6.5.3 


B.3:m 




Yes[] 


C7 


Sending of smsDeliver invoke APDU and 
receipt of return result and return error APDUs 


6.5.3 


B.3:m 




Yes[] 


C8 


Receipt of scAlert invoke APDU and sending of 
return result and return error APDUs 


6.5.3 


B.8:m 




Yes[] 


C9 


Sending of scAlert invoke APDU and receipt of 
return result and return error APDUs 


6.5.4, 6.5.5 


B.8:m 




Yes[] 


C10 


Receipt of smsDeliver invoke APDU and 
sending of return result and return error APDUs 


6.5.4, 6.5.5 


C.4 




Yes[] 


C11 


Coding of Short Message Text as an lASString 


Annex E 


m 




Yes[] 


C12 


Coding of Short Message Text as an Octet 
String 


Annex E 







Yes[] No[] 


C13 


Coding of Short Message Text as an BMPString 


Annex E 







Yes[] No[] 


C14 


Coding of Short Message Text as Compressed 
Coded 


Annex E 







Yes[] No[] 


C15 


Coding of Validity Period in relative format 


Annex E 


BIO: 0.2 


[] 


Yes[] No[] 


C16 


Coding of Validity Period in absolute format 


Annex E 


BIO: 0.2 


[] 


Yes[] No[] 


C17 


Coding of Validity Period in enhanced format 


Annex E 


BIO: 0.2 


[] 


Yes[] No[] 



c.3:If Bl or B2 then m else N/A 
c.4 If B4 or B5 then m else N/A 

A.3.6 Timers 



Item 


Name of Item 


Reference 


Status 


N/A 


Support 


D1 


Support of Timer T1 


6.9.1 


m 




Yes[] 


D2 


Support of Timer T2 


6.9.2 


m 




Yes[] 


D3 


Support of Timer T3 


6.9.3 


m 




Yes[] 


D4 


Support of Timer T4 


6.9.4 


O 




Yes[] 


D5 


Support of Timer T5 


6.9.5 


m 




Yes[] 


D6 


Support of Timer T6 


6.9.6 


B.8:m 




Yes[] 


D7 


Support of Timer T7 


6.9.7 


m 




Yes[] 
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Annex B (informative): 
Examples of message sequences 



This annex describes some typical message flows for SMS. The following conventions are used in the figures of this 
annex: 

^ Protocol message (call-independent) 



^ Service primitive to/from user 

xxx.inv Invoke APDU for operation xxx 

xxx.rr Return result APDU for operation xxx 

xxx .re Return error APDU for operation xxx 

The figures show messages exchanged via Protocol Control between PINXs involved in SMS. Only messages 
relevant to SMS are show. 

Only the relevant information content (i.e. remote operation APDUs) is listed below each message name. The 
Facility information elements containing remote operation APDUs are not explicitly shown. Information with no 
impact on SMS is not shown. 
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B.1 Example message sequence for submission of a 
Short IVIessage 



Sending User 


Sending User 


Service Centre 


Receiving 


Receiving 




PINX 




User 
PINX 


User 



smsSubmit 



request 



smsSubmit 



result 



SETUP 



smsSubmit.inv 



Call 



Proceeding 
CONNECT 



smsSubmit. rr 
RELEASE 



,RE LEASE 



COMPLETE 



SETUP 



smsDeliver.inv 



Call 



Proceeding 



CONNECT 



smsDeliver.rr 



RELEASE 



RELEASE 



COMPLETE 



smsDeliver 
""liiclTcatTdn "^ 



Figure B.1 : Message sequence for submission of a Sliort IVIessage 



ETSI 



43 



ETSI TS 101 991 VI. 1.1 (2001-08) 



Sending User 

Message 

Centre 



Service Centre 



Receiving 
User 
PINX 



Receiving 

User 

Message 

Centre 



smsSubmit 
"reqliesl "f rdrh ^ 
User A 



result to User A 



SETUP 



smsSubmit. inv 



Call 



Proceeding 
CONNECT 



smsSubmit. rr 
RELEASE 



RELEASE 



COMPLETE 



SETUP 



smsDeliver.inv 



Call 



Proceeding 



CONNECT 



smsDeliver.rr 



RELEASE 



RELEASE 



COMPLETE 



SETUP 



smsDeliver.inv 



Call 



Proceeding 



CONNECT 



smsDeliver.rr 



RELEASE 



RELEASE 



COMPLETE 



Figure B.2: Message sequence for submission of a Sliort Message 
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B.2 Example message sequence for the submission of a 
Command 



Sending User 



Sending User 
PINX 



Service Centre 



Receiving User 
PINX 



Receiving User 



smsCommand 



request 



smsCommand 



result 



SETUP 



smsCommand. inv 



Call 



Proceeding 
.CONNECT 



smsCommand. rr 
RELEASE 



RELEASE 



COMPLETE 



Figure B.3: Message sequence for submission of a Command 
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Sending User 


Service Centre 


Receiving 


Receiving 


Message 




User 


User 


Centre 




PINX 


Message 



.smsComm an d- _ ^ 
request from 
User A 



rsmsCommand 



result to User A 



SETUP 



smsCommand.inv 



Call 



Proceeding 



CONNECT 



smsCommand.rr 
RELEASE 



RELEASE 



COMPLETE 



Figure B.4: Message sequence for submission of a Command 



B.3 Message sequence for submission of a Status 
Report 



Sending User 


Sending User 


Service Centre 


Receiving 


Receiving 




PINX 




User 
PINX 


User 



, smsStatusReport 



result 



SE TU P 



smsStatusReport.inv 



Call 



Proceeding 
CONNECT 



smsStatusReport.rr 
RELEASE 



RELEASE 



COMPLETE 



Figure B.5: IVIessage sequence for submission of a Status Report 
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Sending User 

Message 

Centre 



Service Centre 



^_ smsSt_atus Report 
result to User A 



SETUP 



smsStatusReport.inv 



Call 



Proceeding 
CONNECT 



smsStatusReport.rr 
RELEASE 



RELEASE 



COMPLETE 



Receiving 
User 
PINX 



Receiving 

User 

Message 

Centre 



Figure B.6: Message sequence for submission of a Status Report 



B.4 Message sequence for submission of ScAlert 



Sending User 



Sending User 
PINX 



Service 
Centre 



Receiving 
User 
PINX 



Receiving 
User 



SETUP 



scAlert.inv 



Call 



Proceeding 
CONNECT 



scAlert.rr 
RELEASE 



RELEASE 



COMPLETE 



Figure B.7: lUlessage sequence for submission of ScAlert 
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Sending User 
Message Centre 



Service 
Centre 



Receiving 
UserPINX 



Receiving User 
Message Centre 



SETUP 



scAlert.inv 



Call 



Proceeding 



CONNECT 



scAlert.rr 



RELEASE 



RELEASE 



COMPLETE 



SETUP 



scAlert.inv 



Call 



Proceeding 



CONNECT 



scAlert.rr 



RELEASE 



RELEASE 



COMPLETE 



Figure B.8: Message sequence for submission of an ScAiert 
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Annex C (informative): 

Specification and Description Language (SDL) 

representation of procedures 

The diagrams in this annex use the Specification and Description language defined in ITU-T Recommendation Z.IOO. 

Each diagram represents the behaviour of an SMS Supplementary Service Control entity at a particular type of PINX. In 
accordance with the protocol model described in ECMA-165, the Supplementary Service Control entity uses, via the 
Coordination Function, the services of Generic Functional Transport Control and Basic Call Protocol. 

Where an output symbol represents a primitive to the Coordination Function, and that primitive results in a PSSl 
message being sent, the output symbol bears the name of the message and any remote operation APDU(s) contained in 
that message. In case of a message specified in ECMA-143, basic call actions associated with the sending of that 
message are deemed to occur. 

Where an input symbol represents a primitive from the Coordination Function and that primitive results from a PSS 1 
message being received, the input symbol bears the name of the message and any remote operation APDU(s) contained 
in that message. In case of a message specified in ECMA-143, basic call actions associated with the receiving of that 
message are deemed to occur. 

The following abbreviations are used: 



re 


return error APDU 


ind 


indication 


inv 


invoke APDU 


opt. 


optional 


rej 


reject APDU 


rr 


return result APDU 



C.1 SDL Representation of SS-SIVIS at the Sending User 
PINX 

Figure C. 1 shows the behaviour of an SMS Supplementary Service Control entity within the Sending User PINX: 

• Input signals from the left represent messages received from the Sending User; 

• Output signals to the right represent primitives to the Service Centre. 
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SMS-Send- 
Command-wait 



Figure C.1 : Sending User PiNX SDL (slieet 1 of 3) 



SmsCommand.rr 



SmsCommand.re 



SmsCommand.rej 



Timer T2 
expiry 



Stop Timer 
T2 



pos. Result 
to User 



Stop Timer 
T2 



neg. Result 
to User 




SMS-Send- 
Idle 



Figure C.1 : Sending User PiNX SDL (slieet 2 of 3) 
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SMS-Send- 
Submit-wait 



SmsSubmit.rr 



SmsSubmit.re 



SmsSubmit.rej 



Timer T1 
expiry 



Stop Timer 
T1 



Stop Timer 
T1 




pos. Resuit 
to User 



neg. Result 
to User 







SMS-Send- 
Idle 



Figure C.1 : Sending User PINX SDL (slieet 3 of 3) 



C.2 SDL Representation of SS-SMS at the Sending 
IVIessage Centre 

The SDL diagrams representing the behaviour of the Sending Message Centre are equal to those for the Sending User 
PINX, see claused. 



C.3 SDL Representation of SS-SIVIS at the Service 
Centre 

Figure C.2 shows the behaviour of an SMS Supplementary Service Control entity within the Service Centre: 

• Input signals from the left represent primitives received from the Sending User PINX or Sending Message 
Centre; 

• Output signals to the right represent primitives sent to the Receiving User PINX. 
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Yes 



SmsSubmit.re 



SMS-SC- 
idle 




save Short Message, 

assign SCTS and 

priority 



replace existing 
Short Message 




Figure C.2: Service Centre SDL (slieet 1 of 7) 
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SMS-SC 
Del-Wait 



SmsDeliver.rr 



Stop Timer 
T3 




Yes 



internal 

Status Report 

Request 



SMS-SC- 

idle 



Figure C.2: Service Centre SDL (slieet 2 of 7) 
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f 

SMS-SC 


^ 












1 Del-Wait 

v 


/ 




SmsDeliver.re 


~y 




SmsDeliver.re , 


7 


User not available \ 


memory capacity "■ 


\ 






^^'^Validity Period 
^"-■^.^^ expired? 


y 


Yes 














No 











Stop Timer 










T3 






Cc^ 




^^^ Status 
"^-^ Report? 


y 


Yes 


KZ 


V 












No 


^ 


/ 


internal 






\ 


Status Report 
















\ 
\ 


request 




start Timer 
T4 



Yes 



SMS-SC- 
Await-Alert 



Figure C.2: Service Centre SDL (slieet 3 of 7) 
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SMS-SC 
Del-Wait 







SmsDeliver.re 
other error 



Stop Timer 
T3 



deiete SM 




internai 

Status Report 

request 



SmsDeiiver.rej 




SMS-SC- 
idle 



Figure C.2: Service Centre SDL (slieet 4 of 7) 
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Figure C.2: Service Centre SDL (slieet 5 of 7) 
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any State 

except 

SMS-SC-ldle 



SmsCommand.inv 



execute 



successful? ^> 
Yes 


No 






\ 






SmsCommand.rr 


/ 

SmsCommand.re 

\ 






















Figure C.2: Service Centre SDL (slieet 6 of 7) 
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SMS-SC- 
SR-ldle 



internal 

Status Report 

request 



Start T5 



SmsStatus- 
Report.inv 



Timer T5 
expired 




SMS-SC- 
SR-Wait 



SmsStatus- 
Report.rej 



SmsStatus- 
Report.re 



Stop Timer 
T5 




SmsStatus- 
Report.rr 



Stop Timer 
T5 



SMS-SC- 
SR-ldle 



Figure C.2: Service Centre SDL (slieet 7 of 7) 



C.4 SDL Representation of SS-SMS at the Receiving 
User PINX 

C.4.1 Receiving User PINX - Message Centre-case 

Figure C.3 shows the behaviour of an SMS Supplementary Service Control entity within the Receiving User PINX: 
Input messages from the left represent primitives received from the Service Centre; 
Output messages to the right represent primitives sent to the Receiving Message Centre. 
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Figure C.3: Receiving User PINX SDL (slieet 1 of 2) 



SMS-Rec- 
MC-case-ldle 



ScAlert.rr 



Deliver. re 



ScAlert.re 



ScAlert.rej 



ScAlert.rr 



Deliver. re 



ScAlert.re 



ScAlert.rej 



SMS-Rec- 
MC-case-ldie 



Figure C.3: Receiving User PiNX SDL (slieet 2 of 2) 

C.4.2 Receiving User PINX - User Terminal-case 

Figure C.4 shows the behaviour of an SMS Supplementary Service Control entity within the Receiving User PINX: 
Input messages from the left represent primitives received from the Service Centre; 
Output messages to the right represent primitives sent to the Receiving User Terminal. 
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No 


^^^ SMWD ^\ 
*^^^^^ possible? ^^ 

YesT 


SmsDeliver.rr 
\ 












/ SmsDeliver.re 

<^ with SCA saved 
\ indication 














/ SmsDeliver.re 
( without SCA saved 
\ indication 

\ 




save SC Address 










\ 




\ 


1 






' 


\ 
SMS-Rec- 
User-case-ldle 

J 




( SMS-Rec- \ 

User-case- 
\ AlertWait / 

V J 



Figure C.4: Receiving User PiNX SDL (slieet 1 of 3) 
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SMS-Rec- 
User-case- 
AlertWait 




Figure C.4: Receiving User PINX SDL (slieet 2 of 3) 
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SMS-Rec- 
User-case- 
AlertResp 



ScAlert.rr 



Stop Timer 
T6 



delete SC Address 
from SMWD 



SMS-Rec- 
User-case-ldle 




SmsDeliver.re 

without SCA saved 

indication 



save SC Address 



SMS-Rec- 
User-case- 
AlertResp 



Figure C.4: Receiving User PINX SDL (slieet 3 of 3) 



C.5 SDL Representation of SMS at the Receiving 
IVIessage Centre 

Figure C.5 shows the behaviour of an SMS Supplementary Service Control entity within the Receiving Message Centre: 
Input messages from the left represent primitives received from Receiving User PINX; 
Output messages to the right represent primitives sent to the Receiving User Terminal. 
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SmsDeliver.re 

without SCA saved 

indication 



save SC Address 



SmsDeliver.re 

with SCA saved 

indication 



SMS-Rec- 
MC-AlertWait 



Figure C.5: Receiving IVIessage Centre SDL (slieet 1 of 3) 
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SMS-Rec- 
MC-AleilWait 




Indication 
User reachable 



ScAlert.lnv 
toSC 



Start Timer 
T7 



SmsDeliver.inv 
with Priority 



save SM 



SmsDeliver.inv 
without Priority 




ScAlert.inv 
toSC 



Yes 



save SC address 



SmsDeliver.re 



SMS-Rec- 
MC-AiertResp 



SMS-Rec- 
MC-AlertWait 



Figure C.5: Receiving IVIessage Centre SDL (slieet 2 of 3) 
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Figure C.5: Receiving lUlessage Centre SDL (slieet 3 of 3) 
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Annex D (informative): 

Mapping of QSIG-PDUs on GSIVI-PDUs 

D.1 smsSubmit invoke APDU 



smsSubmit invoke APDU (QSIG) 


SmsSubmit (GSIVI) 


Calling Party Number Information Element 


RP-Originating-Address (RP-OA) 
1 Octet Address-Length 
1 Octet Type-of- Address 
1-n Octet Address- Value 


Called Party Number Information Element 


RP-Destination-Address (RP-DA) -SCA 
see RP-OA 


SmsSubmitArg of smsSubmit invoke APDU 




DestinationAddress 


TP-Destination-Address (TP-DA) 
see RP-OA 


OriginatingAddress 


RP-Originating-Address (RP-OA) 
see RP-OA 


MessageReference 


TP-Message-Reference (TP-MR) 
1 Octet (0..255) 


Sm sSubm it Param eter 




Protocolldentifier 


TP-Protocol-ldentifier (TP-PID) 

1 Octet 

clause 9.2.3.9 ETSI TS 100 901 


ValidityPeriod 


TP-Validity-Period (TP-VP) 


ValidityPeriodRel 


1 Octet 


ValidityPeriodAbs 


7 Octets 


ValidityPeriodEnh 


7 Octets 


singleShotSM 




enhanceVP 




ValidityPeriodRel 


relative case, see above 


validityPeriodSec 


0.. 255 seconds 


validityPeriodSemi 


as Service-Centre-Time-Stamp 


StatusReportRequest 


TP-Status-Report-Request (TP-SRR) 
1 Bit 


ReplyPath 


TP-Reply-Path (TP-RP) 
1 Bit 


RejectDuplicates 


TP-Reject-Duplicates (TP-RD) 
1 Bit 


UserData 


TP-User-Data (TP-UD) 


UserDataHeader 




UserDataHeaderChoice 




smscControlParameterHeader 


lEI SMSC Control Parameter 
1 Octet 


concatenatedSBitSMHeader 


lEI Concatenated SM, 8-bit Reference 


concatenatedSBitSM- 
ReferenceNumber 


1 Octet 


maximumNumberOfSBit- 
SMInConcatenatedSM 


1 Octet 


sequenceNumberofSBitSM 


1 Octet 


concatenatedl 6BitSMHeader 


lEI Concatenated SM, 16-bit Reference 


concatenatedl 6BitSM- 
ReferenceNumber 


2 Octet 


maximumNumberOfI 6Bit- 
SMInConcatenatedSM 


1 Octet 


sequenceNumberofI 6BitSM 


1 Octet 


applicationPortSBitHeader 


IE! Application port addressing scheme 


destinationSBitPort 


1 Octet 


originatorSBitPort 


1 Octet 


applicationPortI 6BitHeader 


IE! Application port addressing scheme 


destination16BitPort 


2 Octet 
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smsSubmit invoke APDU (QSIG) 


SmsSubmit (GSIVI) 


originator16BitPort 


2 Octet 


dataHeaderSourcelndicator 


1 Octet 


OriginalSender 




OriginalReceiver 




SMSC 




wirelessControlHeader 


1-nOctet(s) 


GenericUserValue 




parameterValue 




genericUserData 




Class 


TP-Data-Coding-Scheme (TP-DCS) 


Compressed 


1 Bit 


ShortMessageText 




shortMessageTextType 


TP-Data-Coding-Scheme (TP-DCS) 


iASCoded 




octetCoded 




uniCoded 




compressedCoded 




shortMessageTextData 


TP-User-Data 


SmsExtension CHOICE{ 


not mappable 


Extension 




SEQUENCE OF EXTENSION} 






D.2 smsDeliver invoke APDU 


smsDeliver invoke APDU (QSIG) 


SmsDeliver (GSM) 


Calling Party Number Information Element 


RP-Originating-Address (RP-OA) - SCA 
1 Octet Address-Length 
1 Octet Type-of- Address 
1-n Octet Address- Value 


Called Party Number Information Element 


RP-Destination-Address (RP-DA) 
see RP-OA 


SmsDeliverArg of smsDeliver invoke APDU 




OriginatingAddress 


TP-Originating-Address (TP-OA) 
see RP-OA 


DestinationAddress 


TP-Destination-Address (TP-DA) 
see RP-OA 


OriginatingName 


not mappable 


SmDeliverParameter 




Protocolldentifier 


TP-Protocol-ldentifier (TP-PID) 


ServiceCentreTimeStamp 


TP-Service-Centre-Time-Stamp 
(TP-SCTS) 


Priority 


RP-Priority-Request (RP-PRI) 


MoreMessagesToSend 


TP-More-Messages-To-Send(TP-MMS) 


StatusReportlndication 


TP-Status-Report-lndication (TP-SRI) 


ReplyPath 


TP-Reply-Path (TP-RP) 


UserData 


as described in clause D.1 in annex D 


smsExtension CHOICE{ 


not mappable 


Extension 




SEQUENCE OF EXTENSION} 
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D.3 smsStatusReport invoke APDU 


smsStatusReport invoke APDU (QSIG) 


SmsStatusReport (GSM) 


Calling Party Number Information Element 


RP-Originating-Address (RP-OA) - SCA 
1 Octet Address-Lengtii 
1 Octet Type-of- Address 
1-n Octet Address- Value 


Called Party Number Information Element 


RP-Destination-Address (RP-DA) 
see RP-OA 


SmsStatusReportArg of smsStatusReport invoke APDU 




MessageReference 


TP-IVIessage-Reference (TP-IVIR) 


ServiceCentreTimeStamp 


TP-Service-Centre-Time-Stamp 
(TP-SCTS) 


DischargeTime 


TP-Discliarge-Time (TP-DT) 


RecipientAddress 


TP-Recipient-Address (TP-RA) 


RecipientName 


not mappable 


DestinationAddress 




Status 


TP-Status (TP-ST) 


priority 


RP-Priority-Request (RP-PRI) 


IVIorelVlessagesToSend 


TP-IVIore-IVIessages-To-Send(TP-IVIIVIS) 


StatusReportQualifier 


TP-Status-Report-Qualifier (TP-SRQ) 


Protocolldentifier 


TP-Protocol-ldentifier (TP-PID) 


UserData 


as described in clause D.1 


SmsExtension CHOICE{ 


not mappable 


Extension, 




Sequence of Extension} 







D.4 smsCommand invoke APDU 



smsCommand invoke APDU (QSIG) 


SmsCommand (GSIVI) 


SmsCommandArg 




destinationAddress 


TP-Destination-Address (TP-DA) 


messageReference 


TP-Message-Reference (TP-MR) 


messageNumber 


TP-Message-Number (TP-MN) 


protocolldentifier 


TP-Protocol-ldentifier (TP-PID) 


commandType 


TP-Command-Type (TP-CT) 


commandData 


TP-Command-Data (TP-CD) 


statu s Repo rt Requ est 


TP-Status-Report-Request (TP-SRR) 


smsExtension CHOICEf 




Extension, 




Sequence of Extension} 





D.5 smsSubmit return result APDU/smsCommand return 
result APDU 



smsSubmit return result APDU 
smsCommand return result APDU (QSIG) 


SmsSubmitReport - Ack (GSM) 


SmsSubmitRes{ 




ServiceCentreTimeStamp, 


TP-Service-Centre-Time-Stamp (TP-SCTS) 


protocolldentifier, 


TP-Protocol-ldentifier (TP-PID) 


userData, 


TP-User-Data (TP-DU) 


smsExtension] 
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D.6 



smsSubmit return error APDU/smsCommand return 
error APDU 



smsSubmit return error APDU 
smsCommand return error APUD(QSIG) 


SmsSubmitReport - Error (GSM) 


SmsSubmitError SEQUENCE{ 




failureCause 


TP-Failure-Cause (TP-FCS) 


serviceCentreTimeStamp 


TP-Service-Centre-Time-Stamp(TP-SCTS) 


protocol Identifier 


TP-Protocol-ldentifier (TP-PID) 


userData 


TP- Data-Coding-Scheme (TP-DCS) 


TP-User-Data (TP-UD) 



D.7 



smsDeliver return result APDU/smsStatusReport 
return result APDU 



smsDeliver return result APDU 
smsStatusReport return result APDU (QSIG) 


SmsDeliverReport - Ack (GSM) 


SmsDeliverResponseChoice{ 




Null, 




Protocolldentifier, 


TP-Protocol-ldentifier (TP-PID) 


userData, 


TP-User-Data (TP-UD) 


Sequence off 




Protocolldentifier, 




userData}} 




smsExtension 





D.8 smsDeliver return error APDU/smsStatusReport 
return error APDU 



smsDeliver return error APDU 
smsStatusReport return error APDU (QSIG) 


SmsDeliverReport - Error (GSM) 


SmsDeliverError SEQUENCE{ 




failureCause 


TP-Failure-Cause (TP-FCS) 


protocolldentifier 


TP-Protocol-ldentifier (TP-PID) 


userData 


TP- Data-Coding-Scheme (TP-DCS) 


TP-User Date (TP-DU) 


scAddresseSaved} 


not mappable 
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Annex E (normative): 
Description of APDU elements 



NOTE 1 : In this annex the term Sending User is used, although certain information might be provided either by the 
Sending User, the Sending User PINX or the Sending User Message Centre. The point of provision of 
information is dependent on the specific network configuration. It is in the responsibility of the PISN 
entity that composes a certain APDU to provide all necessary information. 

NOTE 2: In this annex the term Receiving User is used, although certain information might be provided either by 
the Receiving User, the Receiving User PINX or the Receiving User Message Centre. The point of 
provision of information is dependent on the specific network configuration. It is in the responsibility of 
the PISN entity that composes a certain APDU to provide all necessary information. 



E.1 Elements in smsSubmit invoke APDU 

Refer to clause 6.5 for the related procedures and further elements of the smsSubmit invoke APDU. 

E.1.1 messageReference 

The messageReference is a value between and 255 which is incremented by one and allocated to each Short Message 
and Command that is sent by the Sending User or the Sending User PINX if not provided by the Sending User. If the 
value is 255 and the messageReference is incremented, it starts again with value 0. 

E.1.2 smsSubmitParameter 
E. 1 .2. 1 protocol Identifier 

The protocolldentifier indicates either a higher layer protocol being used or interworking with a certain type of 
telematic device. Table E. 1 lists all currently defined values for the element protocolldentifier, which are identical to 
those specified in TS 100 901. 

For the straightforward case of simple Short Message transfer the element protocolldentifier is set to "nolw" (0). 

For protocolldentifier values between (1) and (31) it indicates the protocol used between the Sending and Receiving 
Short Message entity. 

If the protocolldentifier contains values between (32) and (63) it indicates interworking with a certain type of telematic 
device and requests the Service Centre to convert the SM into a form suited for that device type. If the destination 
network is ISDN the SC must also select the correct service indicators for connecting to a device of that type. 

If the protocolldentifier contains a "replaceShortMessageType" then the Service Centre on receipt of an smsSubmit 
invoke APDU containing such a protocolldentifier will check the originatingAddress and replace any existing Short 
Message having the same protocolldentifier value and originatingAddress with the content of the new smsSubmit 
invoke APDU. If there is no message to be replaced the Service Centre shall store the new Short Message in the normal 
way. 

If a "replaceShortMessageType" type code is not present the Service Centre shall store the message in the normal way. 
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Table E.1 : Values for element protocolldentlfler (1 octet) 



nolw 





telex 


1 


groupSTelefax 


2 


group4Telefax 


3 


voiceTelephone 


4 


eRMES 


5 


nationalPagingSystem 


6 


videotex 


7 


teletexUnspecifiedCarrier 


8 


teletexPSPDN 


9 


teletexCSPDN 


10 


teletexAnalogPSTN 


11 


teletexDigitallSDN 


12 


uci 


13 


reserved 


14 


reserved 


15 


messageHandlingFacility 


16 


x400MessageHandlingSystem 


17 


internetElectonicMail 


18 


reserved (5 combinations) 


19-23 


values specific to each SC, usage based on 
mutual agreement between the Short Message 
Entity and the SC 


24-30 


gsmMobileStation 


31 


iwlmplicit 


32 


iwTelex 


33 


iwTelefaxG roups 


34 


iwTelefaxGroup4 


35 


iwVoiceTelephone 


36 


iwERMES 


37 


iwNationalPagingSystem 


38 


iwVideotex 


39 


iwTeletexCarrierUnspecified 


40 


iwTeletexPSPDN 


41 


iwTeletexCSPDN 


42 


iwTeletexAnaloguePSTN 


43 


iwTeletexDigitallSDN 


44 


iwUCI 


45 


reserved 


46 


reserved 


47 


IwMessageHandlingFacility 


48 


iwX400MessageHandlingSystem 


49 


iwlnternetElectronicMail 


50 


reserved (5 combinations) 


51 -55 


values specific to each SC, usage based on 
mutual agreement between the Short Message 
Entity and the SC 


56-62 


iwGSMMobileStation 


63 


shortMessageTypeO 


64 


replaceShortMessageTypel 


65 


replaceShortMessageType2 


66 


replaceShortMessageTypeS 


67 


replaceShortMessageType4 


68 


replaceShortMessageTypeS 


69 


replaceShortMessageTypee 


70 


replaceShortMessageType? 


71 


reserved 


72-94 


returnCallMessage 


95 


reserved 


96-124 


meDataDownload 


125 


meDePersonalizationShortMessage 


126 


simDataDownload 


127 
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E. 1.2.2 validityPeriod 

The validityPeriod enables the Sending User to indicate the time period during which the Sending User considers the 
Short Message to be valid, i.e. for how long the SC shall guarantee its existence in the SC and try to deliver the Short 
Message to the Receiving User. After expiry of the Validity Period, the SC shall delete the Short Message. 

The Validity Period may be given in one of the following ways: 

• either relative Validity Period (validityPeriodRel), see table E.2; 

• or absolute Validity Period (validityPeriodAbs), formatted as Generalized Time String; 

• or enhanced Validity Period (validityPeriodeEnh). 

The enhanced Validity Period indicates that the SC shall try only once to send the SM to the Receiving User if element 
singleShotSM is set to TRUE and optionally allows to indicate the Validity Period either: 

• in relative format (see table E.2); 

• or in seconds; 

• or in semi-octet format (validityPeriodSemi), see table E.3. 

The ASN. 1 structure of element validityPeriodEnh might be extended with additional formats for the coding of the 
Validity Period in the future. 

Table E.2: Coding Rules for ValidityPeriodRel (1 octet) 



Value 


Validity Period Value 


to 143 


(value+1) X 5 minutes (i.e. 5 minute, intervals 


up to 12 hours) 


144 to 167 


12 liours + ((value - 143) x 30 minutes) 


168 to 196 


(value-166)x1 day 


197 to 255 


(value- 192) x 1 week 



Table E.3: Coding Example for ValidityPeriodSemi (3 octet) 



Octet 1 


hi 



hi 



hi 
1 


hi 



h2 



h2 
1 


h2 



h2 



24 hours 


Octet 2 


ml 



ml 



ml 

1 


ml 

1 


m2 



m2 



m2 



m2 



30 minutes 


Octet 3 


si 



si 

1 


si 



si 

1 


s2 




s2 

1 


s2 

1 


s2 

1 


57 seconds 



E.1.2.3 statusReportRequest 

If StatusReportRequest is set to TRUE Status Reports are requested by the Sending User from the Sending User for this 
particular Short Message about status changes of the SM in the SC. 
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E. 1.2.4 replyPath 



If replyPath is set to TRUE in an smsSubmit invoke APDU the Sending User requests the Service Centre to handle a 
Short Message sent in reply (reply SM) to this smsSubmit via the same Service Centre. 

If the Sending Users Service Centre and the Receiving User PINX both support the Reply Path option, the following 
definitions and procedures shall apply: 

• the Sending User of the original SM is the Receiving User of the reply SM, this user is called the Sending User 
and 

• the Receiving User of the original SM is the Sending User of the reply SM, this user is called the Receiving 
User. 

The address information in the reply SM shall be set accordingly. 

The Receiving User PINX shall send the reply SM directly to the Service Centre the Sending User, i.e. the Receiving 
Users Service Centre is not involved in the handling of the reply SM. 

E.1.2.5 reject Duplicates 

Reject Duplicates indicates to the SC whether it shall accept or reject a Short Message with the same messageReference 
and destinationAddress as a previously submitted Short Message from the same originatingAddress. 

If rejectDuplicates is set to FALSE the Service Centre will accept a Short Message already held in the SC, if it is set to 
TRUE the Service Centre is instructed to reject such a Short Message. 

If the duplicate Short Message is accepted the duplicate SM shall not overwrite the already held Short Message. For 
procedures to replace an already existing SM by a new SM please refer to the specific protocolldentifier values in 
clause E. 1.2.1. 

If the duplicate Short Message is rejected an appropriate failureCause will be returned to the Sending User in the 
smsDeliver return error APDU. 

E.1.3 userData 

E. 1.3.1 userDataHeader 

If a userDataHeader is present it indicates a special type of Short Message. The element userDataHeader may contain 
one or more of the following headers. 

In GSM-SMS the length of the userDataHeader together with the shortMessageText shall not exceed the maximum 
length of a single (i.e. not concatenated) Short Message, i.e. 140 octets. Due to ASN.l coding it cannot be guaranteed 
within a PISN that this length restrictions are kept. In case of interworking a Service Centre may want to provide a 
specific interworking functionality. This interworking functionality is out of scope of the present document. 

E.I .3.1 .1 smscControlParameterHeader 

This header allows to expand the userDataHeader in a flexible way and controls the Service Centre with regard to the 
request for Status Reports. The Sending User may request a Status Report for: 

• Transaction completed (bit 0), if this bit is set to TRUE a Status Report shall be returned when the Short 
Message transaction is completed; 

• permanent Error (bit 1 ), if set to TRUE a Status Report shall be returned when a permanent error occurs and the 
SC is not making any more transfer attempts; 

• temporary Error, SC not trying anymore (bit 2), if set to TRUE a Status Report shall be returned when a 
temporary error occurs and the SC is not making any more transfer attempts; 
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• temporary Error, SC still trying (bit 3), if set to TRUE a Status Report shall be returned when a temporary error 
occurs and the SC is still trying to transfer the Short Message; 

• cancel a Status Report Request for concatenated Short Messages (bit 6): a Status Report generated by this Short 
Message, due to a permanent or last temporary error, cancels the Status Report Requests of the rest of the Short 
Messages in a concatenated Short Message. This feature can only be used where the SC is aware of the 
segmentation of a concatenated Short Message and is therefore an implementation matter; 

• request the original userDataHeader to be included into the Status Report (bit 7): if set to TRUE the original 
UDH shall be included into the Status Report. 

The smscControlParameterHeader element is only enabled if the statusReportRequest bit of smsSubmit invoke APDU 
is set to TRUE. 

In the case of concatenated Short Messages smscControlParameterHeaders must be identically present in every Short 
Message making up that concatenated Short Message. 

E.1 .3.1 .2 concatenatedSBitSMHeader 

Longer messages (which exceed the length of one Short Message) can be formed by concatenating several Short 

Messages. 

The concatenatedSBitSMHeader contains a concatenatedSBitSMReferenceNumber, a 
maximumNumberOfSBitSMInConcatenatedSM and a sequenceNumberOfSBitSM element. 

The concatenatedSBitSMReferenceNumber element contains a modulo 255 counter and indicates the Reference 
Number of a particular concatenated Short Message. This Reference Number shall remain constant for every Short 
Message which makes up a particular concatenated Short Message. 

The maximumNumberOfSBitSMInConcatenatedSM element is a value in the range to 255 and indicates the total 
number of Short Messages within the concatenated Short Message. The value shall start at 1 and remain constant for 
every Short Message which makes up the concatenated Short Message. If the value is zero then the receiving entity 
shall ignore the whole concatenatedSBitSMHeader. 

The SequenceNumberOfSBitSM element is a value in the range to 255 and indicates the sequence number of a 
particular Short Message within the concatenated Short Message. The value shall start at 1 and increment by one for 
every Short Message sent within the concatenated Short Message. If the value is or the value is greater than the 
maximumNumberOfSBitSMInConcatenatedSM then the receiving entity shall ignore the whole 
concatenatedSBitSMHeader. 

E.1 .3.1 .3 concatenatedl BBitSMHeader 

The concatenated 16BitSMHeader is an enhanced variant of the concatenatedSBitSMHeader, it contains a 
concatenated 16BitSMReferenceNumber, a maximumNumberOfl6BitSMInConcatenatedSM and a 
sequenceNumberOfl6BitSM element. 

The concatenated 16BitSMReferenceNumber element contains a modulo 65536 counter and indicates the Reference 
Number of a particular concatenated Short Message. This Reference Number shall remain constant for every Short 
Message which makes up a particular concatenated Short Message. 

Elements maximumNumberOfl6BitSMInConcatenatedSM and sequenceNumberOfl6BitSM shall be used in the same 
way as the according elements described in clause E.1. 3. 1.2 for concatednatedSBitSMHeader. 

E.1 .3.1 .4 application PortSBitHeader 

The applicationPortSBitHeader element allows Short Messages to be routed directly to one of multiple applications in 
the Terminal Equipment. The applicationPortSBitHeader contains a destinationSBitPort and an originatorSBitPort 
element. 

The destinationSBitPort element is a value in the range to 255 and indicates the receiving port, i.e. application, in the 
receiving device. 
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The originatingSBitPort is a value in the range to 255 and indicates the sending port, i.e. application, in the sending 
device. 

Port numbers in the range to 239 are reserved and port numbers in the range 240 to 255 are available for allocation by 
applications. 

In the case of concatenated Short Messages the applicationPortSBitHeader shall be included in every Short Message 
making up the concatenated Short Message. 

E.1 .3.1 .5 applicationPortI 6BitHeader 

The apphcationPortl6BitHeader element allows Short Messages to be routed directly to one of multiple applications in 
the Terminal Equipment. The applicationPortI 6BitHeader contains a destination 16BitPort and an originator 16BitPort 
element. 

The destination 16BitPort element is a value in the range to 65535 and indicates the receiving port, i.e. application, in 
the receiving device. 

The originating 16BitPort is a value in the range to 65535 and indicates the sending port, i.e. application, in the 
sending device. 

Port numbers in the range to 15999 are as allocated by I AN A (http://www.IANA.com) , port numbers in the range 
16000 to 16999 are available for allocation by applications, all other values are reserved. 

In the case of concatenated Short Messages the applicationPortI 6BitHeader shall be included in every Short Message 
making up the concatenated Short Message. 

E.1 .3.1 .6 dataHeaderSourcelndicator 

The dataHeaderSourcelndicator element is used to separate userDataHeaders created by the Sending User from 
userDataHeaders created by the Service Centre and by the Receiving User. The dataHeaderSourcelndicator is placed in 
front of the content inserted by the source. The indicated content (one or more User Data Header) ends at the next 
dataHeaderSourcelndicator or at the end of the User Data Headers. The Separator is intended to be used especially in 
Status Reports, but can also be used by the Service Centre to add information into a Short Message. The default content 
for a User Data Header in a smsDeliver is the headers inserted by the Sending User, and the default content for a User 
Data Header in a smsStatusReport is the headers copied from the smsDeliver report. 

The dataHeaderSourcelndicator may contain the values originalSender (1, valid in case of Status Report), 
originalReceiver (2, valid in case of Status Report) or SMSC (3, can occur in any message or report). 

E.1. 3. 1.7 wirelessControlHeader 

The wirelessControlHeader element is used to transport Wireless-Control-Message-Protocol (WCMP) messages. The 
OCTET STRING associated with the wirelessControlHeader shall contain a WCMP protocol data unit. 

In the case of concatenated Short Messages the wirelessControlHeader shall be included identically in every Short 
Message making up the concatenated Short Message. 

E.1. 3. 1.8 genericUserValue 

The genericUserValue element is reserved for further extensions introduced in GSM 03.40. 

E.1. 3. 2 class 

The class element indicates how to handle a received Short Message with respect to displaying, storing and 
acknowledging. 

If element class is set to the Receiving User PINX/Receiving User Message Centre shall display the Short Message 
immediately and send an smsDeliver return result APDU to the Service Centre, irrespective of whether there is memory 
available or not. The Short Message shall not automatically be stored. If it is not possible to display the Short Message 
automatically the Receiving User PINX/Receiving User Message Centre shall treat the Short Message as though there 
were no message class. 
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If element class is set to 1 the Receiving User PINX/Receiving User Message Centre shall send a smsDeliver return 
result APDU to the Service Centre when the Short Message has reached the Receiving User PINX/Receiving User 
Message Centre and can be stored. 

If element class is set to 2 the Receiving User PINX/Receiving User Message Centre shall ensure that the Short 
Message has been transferred to the SMS data field in the SIM before it sends an smsDeliver return result APDU. 

If element class is set to 3 it indicates GSM specific handling and shall be treated as if value 1 was indicated. 

E.1.3.3 compressed 

If it is set to ONE it indicates that the text contained in shortMessageText is compressed using the standard compression 
algorithm. The standard compression algorithm is described in GSM 03.42. 

E.1.3.4 ShortMessageText 

The shortMessageText element contains one of the following elements. 

E.1. 3.4.1 iASCoded 

The iASCoded element contains between and 140 byte Short Message Text, i.e. a maximum of 160 characters. 

E.1. 3.4.2 octetCoded 

The octetCoded element contains between and 140 byte Short Message Text, i.e. a maximum of 140 characters. 

E.1. 3.4.3 uniCoded 

The uniCoded element contains between and 140 byte Short Message Text coded according to ISO/IEC 10646-1, 
i.e. a maximum of 70 characters. 

E. 1.3.4.4 compressedCoded 

The compressedCoded element contains between and 140 byte compressed Short Message Text including the 
Compressed Data Header and Footer as described in GSM 03.42. If the Short Message Text is compressed the 
compressed element shall be set to ONE. 

E.2 Elements in smsSubmit return result APDU 

Refer to clause 6.5 for the related procedures and further elements of the smsSubmit return result APDU. 



E.2.1 serviceCentreTlmeStamp 



The serviceCentreTlmeStamp indicates the time of arrival of a Short Message at the Service Centre. The Service- 
Centre-Time-Stamp, and any other time value representations that are defined in the present document, represent the 
time local to the sending entity of the specific APDU. 

The date and time representation follows ISO 8601. 

The serviceCentreTlmeStamp contains the time of arrival with an accuracy of a second. If two or more messages arrive 
at the Service Centre at the same time the SC shall modify the serviceCentreTlmeStamp in such a way that; 

• all messages to one Receiving User contain different time stamps; 

• the modification of the time stamps is kept to a minimum. 
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E.2.2 protocol Identifier 



The protocolldentifier shall be sent as received within the smsSubmit invoke APDU, see clause E. 1.2.1. 

E.2.3 userData 

The userData element in an smsSubmit return result APDU is only available for use by the Service Centre. The 
elements shall be used as described in clause E.1.3. 

If included the userData element in an smsSubmit return result APDU shall include the userData as received in the 
smsSubmit invoke APDU. 

It is possible for the Service Centre to include further User Data Headers in the smsSubmit return result APDU by 
adding the dataHeaderSourcelndicator and other userDataHeader elements. 



E.3 Elements in smsSubmit return error APDU 
E.3.1 failureCause 

Element failureCause is a value in the range to 255 and contains the reason for the smsSubmit failure. 

For the purpose of giving a better overview, table E.4 lists all possible failureCause values which might occur in a 
return error APDU for any SMS specific invoke APDU (all other values are reserved). 

Table E.4: Possible Failure Causes 



failureCause 


Value 


Reason 


telematiclnterworkingNotSupported 


(128) 


Tlie telematic interworking as requested in 
element protocolldentifier cannot be provided by 
the Service Centre. 


shortMessageTypeONotSupported 


(129) 


The Message Type as indicated in element 
protocolldentifier is not supported by the Service 
Centre. 


canNotReplaceShortMessage 


(130) 


A SM cannot be replaced as requested in element 
protocolldentifier. 


unspecifiedProtocolldentifierError 


(143) 


An unspecified error due to the processing of 
element protocolldentifier has occurred. 


alphabetNotSupported 


(144) 


The indicated alphabet (either lASCoded or 
octetCoded or uniCoded or compressedCoded) in 
element shortMessageText is not supported by 
the receiving entity. 


messageClassNotSupported 


(145) 


The class of the SM as indicated in element class 
is not supported. 


unspecified DcsError 


(159) 


An unspecified error due to the processing of 
element shortMessageText and class has 
occurred. 


commandCanNotBeActloned 


(160) 


The command, as indicated in element 
commandType in the smsCommand invoke 
APDU, cannot be actioned by the SC. No further 
reason given. 


commandUnsupported 


(161) 


The command, as indicated in element 
commandType in the smsCommand invoke 
APDU, is not supported by the SC. 


unspecifiedCommand Error 


(175) 


An unspecified error due to the processing of the 
smsCommand invoke APDU has occurred. 


pduNotSupported 


(176) 


This error can only occur in interworking cases 
with other networks, as the other network might 
send this failureCause. Within a PISN 
configuration this error will be handled by a reject 
APDU to the specific invoke APDU. 


scBusy 


(192) 


The SC cannot handle the received invoke APDU. 
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failureCause 


Value 


Reason 


noScSubscription 


(193) 


The user sending tlie invoke APDU and identified 
by tlie related address information (i.e. 
PartyNumber element) is not subscribed at the 
SC, i.e. is not allowed to use SMS at this SC. 


scSystem Failure 


(194) 


A general SC system failure has occurred. 


invalidSmeAddress 


(195) 


The address (i.e. PartyNumber) of the Short 
Message Entity which should receive the invoke 
APDU is not valid. 


destinationSmeBarred 


(196) 


The Short Message Entity which should receive 
the invoke APDU is barred and therefore cannot 
handle the invoke APDU. 


sm RejectedDuplicateSm 


(197) 


Element rejectDuplicates in an smsSubmitlnvoke 
APDU was set to TRUE and the SC recognized 
the received SM as already held in the SC, due to 
identical elements messageReference and 
destinationAddress and originatingAddress of the 
held and the newly received SM. 


validityPeriodFormatNotSupported 


(198) 


The format of element validityPeriod is not 
supported by the SC. 


validityPeriodNotSupported 


(199) 


The Validity Period functionality is not supported 
by the SC. 


simSmsStorageFull 


(208) 


This error can only occur if the Receiving Users 
terminal equipment provides a so-called SIM 
storage, as available e.g. in chip cards. The 
Receiving Users SIM storage does not allow to 
store further Short Messages. 


noSmsStorageCapabilityinSIM 


(209) 


This error can only occur if the Receiving Users 
terminal equipment provides a so-called SIM 
storage, as available e.g. in chip cards. The 
Receiving Users SIM storage does generally not 
allow to store Short Messages. 


errorlnTE 


(210) 


An error in the Receiving Users terminal 
equipment has occurred. 


memoryCapacityExceeded 


(211) 


The SM was not stored as the Short Message 
Entity receiving the invoke APDU did not have 
memory available. 


simApplicationToolkitBusy 


(212) 


This error can only occur if the Receiving Users 
terminal equipment provides a so-called SIM 
storage, as available e.g. in chip cards. The 
Receiving Users SIM storage did report a 
Toolkit-Busy error. 


simDataDownloadError 


(213) 


This error can only occur if the Receiving Users 
terminal equipment provides a so-called SIM 
storage, as available e.g. in chip cards. The 
Receiving Users SIM storage did report a 
Data-Download error. 


unspecifiedErrorCause 


(255) 


An unspecified error occurred. 



E.3.2 serviceCentreTimeStamp 

As described in clause E.2.1. 

E.3.3 protocol Identifier 

As described in clause E. 1.2.1. 
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E.3.4 userData 

The userData element in an smsSubmit return error APDU is only available for use by the Service Centre. The elements 
shall be used as described in clause 1.3 in. 

If included the userData element in an smsSubmit return error APDU shall include the userData as received in the 
smsSubmit invoke APDU. 

It is possible for the Service Centre to include further User Data Headers in the smsSubmit return error APDU by 
adding the dataHeaderSourcelndicator and other userDataHeader elements. 



E.4 Elements in smsDeliver invoke APDU 
E.4.1 originatingName 

Name of the Sending User if available to the Service Centre. Name restrictions shall apply accordingly. 

E.4. 2 smsDeliverParameter 
E.4. 2.1 protocol Identifier 

As described in clause E. 1.2.1. 

E.4. 2. 2 serviceCentreTimeStamp 

As described in clause E.2.1. 

E.4. 2. 3 priority 

If the priority element is set to FALSE the message transfer should be stopped if the SC address is already contained in 
the SMWD field. 

E.4. 2. 4 moreMessagesToSend 

If the moreMessagesToSend element is set to TRUE it indicates that there are more messages waiting for this Receiving 
User in that particular Service Centre. Messages as used here refers to both Status Reports (for Short Messages for 
which this user acted as a Sending User) and Short Messages. 

E.4. 2. 5 statusReportlndication 

If the StatusReportlndication element is set to TRUE it indicates that a Status Report will be returned to the Sending 
User of the Short Message. 

E.4.2.6 replyPath 

If replyPath is set to TRUE it indicates that the reply path for the Short Message exists, e.g. that the Receiving User may 
reply via this Service Centre although it may not be the default Service Centre. 

Refer to clause clause E. 1.2.4 for further details. 
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E.4.3 userData 

This element contains the userData element as received from the Sending User PINX/Sending User Message Centre in 
the smsSubmit invoke APDU as described in clause E.1.3. 

It is possible for the Service Centre to include further User Data Headers in the smsDeliver invoke APDU by adding the 
dataHeaderSourcelndicator and other userDataHeader elements. 



E.5 Elements in smsDeliver return result APDU 

The smsDeliver return result APDU shall either contain none, one or both of the following two elements. 

E.5.1 protocolldentifier 

As described in clause E. 1.2.1. 

E.5. 2 userData 

The userData element in an smsDeliver return result APDU is only available for use by the Receiving User 
PINX/Receiving User Message Centre and contains elements as described in clause E.1.3. 

It is possible for the Receiving User PINX/Receiving User Message Centre to include further User Data Headers in the 
smsDeliver return result APDU by adding the dataHeaderSourcelndicator and other userDataHeader elements. 

E.6 Elements in smsDeliver return error APDU 
E.6.1 failureCause 

The failureCause element contains the reason for the smsDeliver failure. All possible failureCauses are listed and 
described in clause E.3.1. 

E.6. 2 protocolldentifier 

As described in clause E. 1.2.1. 

E.6.3 userData 

If included the userData element in a smsDeliver return error APDU shall include the userData as received in the 
smsDeliver invoke APDU. 

It is possible for the Receiving User PINX/Receiving User Message Centre to include further User Data Headers in the 
smsDeliver return error APDU by adding the dataHeaderSourcelndicator and other userDataHeader elements. 

The userData element shall be used according to clause E.1.3. 

E.6. 4 scAddressSaved 

If the scAddressSaved element is set to TRUE it indicates that the Receiving User PINX/Receiving User Message 
Centre stored the Service Centre address in the SMWD, hence the Service Centre does not have to repeat the delivery 
procedure periodically and the Receiving User PINX/Receiving User Message Centre will send an scAlert invoke 
APDU. 
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E.7 Elements in smsStatusReport invoke APDU 



E.7.1 messageReference 



The messageReference in an smsStatusReport invoke APDU shall contain the messageReference of the smsSubmit or 
smsCommand invoke APDU to which the Status Report refers. If the Status Report refers to an smsCommand invoke 
APDU and the commandType was an "Enquiry" the messageReference element shall contain the messageNumber 
contained in that smsCommand invoke APDU (e.g. the messageReference of the previously received Short Message to 
which the Enquiry refers). 



E.7. 2 serviceCentreTimeStamp 



The serviceCentreTimeStamp element shall contain the serviceCentreTimeStamp of the Short Message to which the 
Status Report refers. This will allow the Sending User to associate a Short Message with a Status Report by correlating 
the serviceCentreTimeStamps. 



E.7. 3 dischargeTime 



The dischargeTime element indicates the time at which a previously submitted Short Message was successfully 
delivered to the Receiving User or attempted to deliver to the Receiving User or disposed of by the SC. The 
representation of the dischargeTime follows ISO 8601. 

In the case of "transaction completed" the time shall be the time of the completion of the transaction. In the case of "SC 
still trying to transfer SM" the time shall be the time of the last transfer attempt. In the case of "permanent or temporary 
error - SC not making any more transfer attempts" the time shall be time of either the last transfer attempt of the time at 
which the SC disposed of the SM according to the Status outcome in the status element. 

E.7. 4 recipientAddress 

The recipientAddress element contains the address of the Receiving User of the previously submitted Short Message. 



E.7. 5 recipientName 



The recipientName element contains the name of the Receiving User of the previously submitted Short Message if it is 
available to the Service Centre and not restricted. Name restrictions shall apply accordingly. 
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E.7.6 Status 

The status element indicates the status of a previously submitted Short Message and certain Commands for which a 
Status Report has been requested. 

Table E.5: Possible values for status element 



Status 


Value 


smReceivedBySME 





smForwardedButSCUnableToConfirmDelivery 


1 


sm ReplacedByTheSC 


2 


tempCongestion 


32 


tempSMEBusy 


33 


tempNoResponseFromSME 


34 


tempServiceRejected 


35 


qualityOfServiceNotAvailable 


36 


tempErrorlnSME 


37 


remoteProcedureError 


64 


incompatibleDestination 


65 


connectionRejectedBySME 


66 


notObtainable 


67 


permanentQualityOfServiceNotAvailable 


68 


nolnterworkingAvailable 


69 


iwValidity Period Expired 


70 


smDeletedByOriginatingSIVIE 


71 


smDeletedBySCAdministration 


72 


smDoesNotExist 


73 


congestion 


96 


sIVIEBusy 


97 


noResponseFromSIVIE 


98 


serviceRejected 


99 


tempQualityOfServiceNotAvailable 


100 


errorlnSIVIE 


101 



E.7.7 priority 

As described in clause E.4.2.3. 

E.7.8 morelVlessagesToSend 

As described in clause E.4.2.4. 

E.7.9 statusReportQualifier 

If the StatusReportQualifier is set to FALSE the Status Report is the result of a Short Message, if it is set to TRUE the 
Status Report is the result of a Command, e.g. an Enquiry. 



E.7.10 protocolldentifier 



The protocolldentifier element in an smsStatusReport invoke APDU shall contain the same settings as received in the 
related smsSubmit invoke APDU, described in clause E. 1.2.1. 
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E.7.11 userData 

If included the userData element in a smsStatusReport invoke APDU shall include the userData as received in the 
smsDeliver return result APDU. 

It is possible for the Service Centre to include further User Data Headers in the smsStatusReport invoke APDU by 
adding the dataHeaderSourcelndicator and other userDataHeader elements. 

The userData element shall be used according to clause E.1.3. 



E.8 Elements in smsStatusReport return result APDU 

The smsStatusReport return result APDU shall either contain one or both of the following elements. 

E.8.1 protocolldentifier 

As described in clause E. 1.2.1. 

E.8.2 userData 

If included the userData element in a smsStatusReport return result APDU shall include the userData as received in the 
smsStatusReport invoke APDU. 

It is possible for the Sending User PINX/Sending User Message Centre to include further User Data Headers in the 
smsStatusReport return result APDU by adding the dataHeaderSourcelndicator and other userDataHeader elements. 

The userData element shall be used according to clause E.1.3. 

E.9 Elements in smsStatusReport return error APDU 
E.9.1 failureCause 

As described in clause E.3.1. 

E.9. 2 protocolldentifier 

As described in clause E. 1.2.1. 

E.9.3 userData 

If included the userData element in a smsStatusReport return error APDU shall include the userData as received in the 
smsStatusReport invoke APDU. 

It is possible for the Sending User PINX/Sending User Message Centre to include further User Data Headers in the 
smsStatusReport return error APDU by adding the dataHeaderSourcelndicator and other userDataHeader elements. 

The userData element shall be used according to clause E.1.3. 

E.9. 4 scAddressSaved 

As described in clause E.6.4. 
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E.10 Elements in smsCommand invoke APDU 



E.10.1 messageReference 



The messageReference is a value between and 255 which is incremented by one and allocated to each Command that 
is sent by the Sending User. If the value is 255 and the messageReference is incremented, it starts again with value 0. 



E.10.2 messageNumber 



The messageNumber element contains the Message Reference of the Short Message to which the Command refers, e.g. 
the messageReference of a previously submitted Short Message. The messageNumber is only necessary for Commands 
that operate on a specific Short Message, else it shall be ignored. 

E.10.3 protocolldentifier 

As described in clause E. 1.2.1. 



E.10.4 commandType 



The commandType element specifies which operation is to be performed on a Short Message. The commandType 
consists of one octet and can be set to "Enquiry" (0), "CancelSRR" (1), "DeletePreviouslySubmittedSM" (2) and 
"EnableSRRrelatingToPreviouslySubmittedSM" (3). The values from 224 to 255 are specific for each Service Centre, 
all other values are reserved. 

E.10.5 commandData 

The commandData element contains data related to the operation requested by the Sending User. 



E.10.6 statusReportRequest 



The StatusReportRequest element indicates whether or not the Command requests a Status Report. It shall be set TRUE 
for commandType "Enquiry", otherwise it shall be set FALSE. 



E.1 1 Elements in smsCommand return result APDU 
E.11.1 serviceCentreTimeStamp 

As described in clause E.2.1. 

E.1 1.2 protocolldentifier 

As described in clause E. 1.2.1. 
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E.11.3 userData 

The userData element in an smsCommand return result APDU is only available for use by the Service Centre. 

It is possible for the Service Centre to include further User Data Headers in the smsCommand return result APDU by 
adding the dataHeaderSourcelndicator and other userDataHeader elements. 

The userData element shall be used according to clause E.1.3. 

E.1 2 Elements in smsCommand return error APDU 
E.12.1 failureCause 

As described in clause E.3.1. 

E.1 2.2 serviceCentreTimeStamp 

As described in clause E.2.1. 

E.1 2.3 protocol Identifier 

As described in clause E.1. 2.1. 

E.1 2.4 userData 

The userData element in an smsCommand return error APDU is only available for use by the Service Centre. 

It is possible for the Service Centre to include further userDataHeader in the smsCommand return error APDU by 
adding the dataHeaderSourcelndicator and other userDataHeader elements. 

The userData element shall be used according to clause E.1.3. 
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